|
bump?
c'mon, speculators, I'm sure some of you know.
more investigation from me: BTCChina allows you to "loan" funds, but does
not (as far as I see) allow you to lend funds. This means they are lending out themselves.
Weird (or rather: smells of fractional reserve).
|
|
|
|
|
yeah that's a strange scheme. Why are they doing this though? Just encouraging people keeping BTC on their site?
To be fair to bitfinex, I have to add that their swap rates are market-determined.
Why would people manually place swap offers at as low as 0.001% daily is beyond me,
but apparently that's what's happening.
|
|
|
|
|
short version: Offering BTC swaps on Chinese exchanges: are there any (hidden) fees, limitation, requirements?
long version: Trying to profit from the bear market without trading (which I am not good at).
I tried offering BTC swaps at Bitfinex, and I have no complaints apart from that
the interest rate has become too low.
Right now it is 0.0055% daily, which, in my opinion, is completely useless.
(To put it more correctly, not worth the risk of keeping one's BTC on an exchange.)
On the other hand, OKcoin swaps market seems to offer 0.1% daily (and that at no
fees as opposed to bitfinex' 15%), which seems pretty good.
So I am considering putting some BTC there, and I'm wondering whether there are any "surprises"
waiting. Such as:
- hidden requirements, like: you can't withdraw your BTC unless you do our KYC check.
(I'd prefer not doing any verification, apart from email verification)
- hidden fees
- crippling withdrawal limits
- ...
I haven't checked the other Chinese exchanges, but I'd appreciate any feedback/experience accounts
on those as well.
|
|
|
|
http://www.businessinsider.com.au/Almost all of the deep web’s major drug marketplaces are currently offline, raising the possibility that the FBI has caused severe disruption to the online drug trade. Agora, Alpaca, BlueSky, C9, Hyrda, Pandora, and the Silk Road are all currently offline. Damn, is that true? Are they all down as well? agora and evolution appear to be online. Hydra displays a "hidden site seized" notice. Don't know about the rest. |
|
|
|
|
what you are doing is called steganography.
Exchanging secret information in such a way that it looks like all that being
exchanged is public. Practically most used (and not secure) steganographic schemes use embedding secrets in the least significant bits of pictures, but any other "cover source" can be used instead of pictures, like music, video, chat messages, or as you suggest bitcoin transactions.
There are two main characteristics of a steganographic protocol.
- Secrecy. The messages exchanged should look "innocent", in the sense
that a passive observed should not be able to tell that secret information is being
passed. This what you are trying to achieve by not using OP_RETURN, but
in fact that's not all to look out for. It might be that your protocol creates a certain
pattern of exchanges, like a transaction from A to B followed by B to A followed by A to B
(this is just hypothetical. I think your protocol doesn't result in any such pattern, but I didn't
really understand it very well.)
- Efficiency. The ratio between the amount of secret information passed and the total amount of data sent.
I suppose for bitcoin there's another measure of efficiency, namely the cost per secret bit.
I think bitcoin can be used for steganography in various ways (I can think about a few), probably more efficiently than you suggest. However, secrecy, which is not a big problem if you want to send
short text messages, will become major concern when you want a reliable source for sending
megabytes of data. So in the end of the day, bitcoin may be not the best cover source out there.
Also, googling "bitcoin steganography" brings out a 3-years-old thread on this forum, where a guy wrote up
a paper suggesting a bitcoin protocol, but wants 1 BTC per download (I'm not giving a link because
I don't want to promote him, besides I'm not sure the download link is still up).
|
|
|
|
|
.. more about this:
there's actually the opposite kind of manipulation (or rather attack) possible:
empty blocks. Right now they exist but don't hurt anyone; here they would push
the max block size down, hurting the network.
|
|
|
|
|
yep, median would work much better than the mean, and a group of <50% miners would only have limited power.
However, I don't quite agree with the reliance on no collusion above 50%.
I understand the premise that a group of >50% miners can do something much worse:
a doublespend. But it is not at all the same type of collusion.
Assembling a group to collude for a doublespend and destroying the credibility
and value of bitcoin in the eyes of the public is one thing, and assembling a group
to push the max block size to infinity, in order to slowly push out low-bandwidth competitors
from mining, is a very different thing. It seems the latter is much easier.
This said, I find both this and NewLiberty's idea interesting.
|
|
|
|
a miner can include into his block a transaction with an arbitrary large fee (which he gets back of course), throwing the mean off the chart.
What about the following modification: a1) fold a modified p2ppool protocol into the mainline protocol a2) require that transactions mined into the mainline blockchain have to be seen in the majority of p2ppool blocks a3) p2ppool then has an additional function of proof-of-propagation: at least 50% of miners have seen the tx a4) we can then individually adjust the fees and incentives individually for: a4.1) permanent storage of transactions (in the mainline blockchain) a4.2) propagation of transactions (in the p2ppool blockchain, which is ephemeral) Right now the problem is that miners receive all fees due, both for permanent storage and for network propagation. Another idea in the similar vein: b1) make mining a moral equivalent of a second-price auction: the mining fees of block X accrue to the miner of block X+1 b2) possibly even replace 1 above with a higher, constant natural number N. Late edit: b3) reduce the coinbase maturity requirement by N Later edit: b4) since nowadays the fees are very low compared to subsidy, (b3) would imply a temporary gap of global mining income. Subsidy of block X accrues to the miner of X, fees of block X accrue to the miner of block X+N. End of edits. Both proposals above aim to incentivize and enforce propagation of the transactions on the network and discourage self-mining of non-public transactions and self-dealing on the mining fee market. a) is vulnerable to sybil attacks b) smothers the incentive to include any transactions in blocks: why should I (as a miner) include a tx if the fee would go to someone else? Also it seems both are too disruptive to be implemented in bitcoin. Anything this much different would take an altcoin to be tried. |
|
|
|
My 2uBTC on this issue:
Instead of guessing the costs of the network via extrapolation, code in a constant-cost negative feedback mechanism. For example, similar to difficulty adjustments, if mean non-coinbase block reward > 1 BTC, increase max size. If mean block reward < 1 BTC, decrease max size (floor of 1MB).
a miner can include into his block a transaction with an arbitrary large fee (which he gets back of course), throwing the mean off the chart. |
|
|
|
It would seem that there could be a simple mathematical progressive increase/decrease, which is based on the factual block chain needs and realities of the time that can work forever into the future.
Here is an example that can come close to Gavin's first proposal of 50% increase per year.
If average block size of last 2 weeks is 60-75% of the maximum, increase maximum 1%, if >75% increase 2%
If average block size of last 2 weeks is 25-40% of the maximum decrease maximum 1%, if <29% decrease 2%
Something like this, would have no external dependencies, would adjust based on what future events may come, and won't expire or need to be changed.
These percentage numbers are ones that I picked arbitrarily. They are complete guesses and so I don't like them anymore than any other number. This is just to create a model of the sort of thing that would be better than extrapolating. To do even better, we can do a regression analysis of previous blocks to see where we would be now and tune it further from there.
This may be manipulable: miners with good bandwidth can start filling the blocks to capacity, to increase the max and push miners with smaller bandwidth out of competition. |
|
|
|
so if the bandwith growth happens to stop in 10 years
Why would it? Why on earth would it??? It's all about predicting the value of some constants in the future. I've no idea what they would be in 10 years. I'm sure there are people who have much better idea than I. While (I think we'd all agree that) predicting technology decades ahead is hard, it is not impossible that a group of specialists, after a thorough discussion, could get the prediction about right. May be we should all bet on them to make it. (No sarcasm intended.) However it seems reasonable to me to try to find a solution that would involve predicting fewer constants, and minimize the impact of not getting these few constants right. |
|
|
|
10: 769
...
20: 44337
so if the bandwith growth happens to stop in 10 years, then in 20 years you end up with max block of 44337 whereas the "comfortable" size (if we consider 1MB being comfortable right now) is only 769. I call that "easy to overshoot" because predicting technology for decades ahead is hard, and the difference between these numbers is huge. |
|
|
|
Of course one can say, let's put it 50% per year until the bandwidth stops growing that fast,
and then we fork again. But this only postpones the problem. Trying to predict now exactly when this happens, and to program for it now, seems futile.
Okey dokey. My latest straw-man proposal is 40% per year growth for 20 years. That seems like a reasonable compromise based on current conditions and trends. You seem to be looking hard for reasons not to grow the block size-- for example, yes, CPU clock speed growth has stopped. But number of cores put onto a chip continues to grow, so Moore's Law continues. (and the reference implementation already uses as many cores as you have to validate transactions) Actually, I'm not looking for reasons not to grow the block size: I suggested sub-exponential growth instead, like, for example, quadratic (that was a serious suggestion). About the 40% over the 20 years - what if you overshoot, by, say, 10 years? And as a result of 40% growth over the 10 extra years the max block size grows so much that it's effectively infinite? ( 1.4^10 ~ 30). The point being, with an exponent it's too easy to overshoot. Then if you want to solve the resulting problem by another fork, it may be much harder to reach a consensus, since the problem will be of a very different nature (too much centralization vs too expensive transactions). |
|
|
|
Because exponential growth is unsustainable
Not inherently. It depends on the rate of growth and what is growing. For example, a 1% per year addition to bandwidth is exceedingly conservative, based on historical evidence. it is bound to cap at some point in the near future.
physical parameters have physical limits, which are constants. So unbounded growth is unsustainable. Even linear growth. However, with less than exponential growth one can expect it to be negligible from some point on (that is, less than x% per year for any x). Looking at the past data and just extrapolating the exponent one sees is a myopic reasoning: the exponential growth is only due to the novelty of the given technology. It will stop when the saturation is reached, that is, when the physical limit of the parameter in question is close. If you want a concrete example, look at the CPU clock growth over the next few decades. Define 'near future'. Is that 5 years, 10 years, 40? And what makes you say that? It's easy to make a general unsupported statement. Don't be intellectually lazy. Show the basis for your reasoning, please.
I'm not making predictions on constants that we don't know; but when speaking about exponential growth it is not even necessary. Want to know how fast the exponent growth? Take your 50% growth, and just out of curiosity see for which n your (1.5)^n exceeds the number of atoms in the universe. Gives some idea. Yes, you can put 1% or (1.01)^n, the difference is not important. Of course one can say, let's put it 50% per year until the bandwidth stops growing that fast, and then we fork again. But this only postpones the problem. Trying to predict now exactly when this happens, and to program for it now, seems futile. |
|
|
|
why not linear growth, like +n MB per block halving, or quadratic like +n MB per n'th block halving?
Why would we choose linear growth when the trend is exponential growth? Because exponential growth is unsustainable, it is bound to cap at some point in the near future. We have no idea at what constant it will reach saturation. Instead we can try a slow growth of the parameter, knowing that it will surpass any constant and thus probably catch up with the real limit at some point, and hoping that the growth is slow enough to be at most a minor nuisance after that. |
|
|
|
|
doesn't matter how high is the physical limit, with exponential growth (any x% per year) rule it is going to be reached and exceeded, whereupon keeping the rule is just as well as making the max size infinite.
why not linear growth, like +n MB per block halving, or quadratic like +n MB per n'th block halving?
|
|
|
|
|
probably a man-in-the-middle attack performed by a TOR exit node.
just a reminder that in general it is not a good idea to use TOR to access
clearnet (that is, "normal" web addresses, as opposed to TOR hidden services).
What TOR makes secure in this case is the connection to the so-called TOR exit
node, which connects for you to your destination address, and sends you
the data back over the TOR network, thus acting as a proxy. However, you are effectively trusting
the exit node not to fiddle with the data it forwards. Since the exit node can be
anybody (you can set up one, too), there is really no reason to trust it.
In particular, they can redirct your blockchain.info request to a fake site,
or strip your communication of its SSL and read all of it.
If you still want to use TOR to access clear net, and want to make this secure,
you have to download and install SSL certificates of every site you are going to use, in this
case of blockchain.info .
|
|
|
|
|
bc.info removed the spammer's message (and probably blacklisted them).
If Eligius blacklists them too, this spammer's business may fail.
(These 1 satoshi transactions are non-standard and the spammer has to submit
them directly to a pool that accepts them, which is only Eligius.)
|
|
|
|
|
most likely a bug of blockchain.info
5 blocks in a row orphaned means that there is an alternative chain of at least 6 blocks,
which is nowhere to be seen. Had it been present it'd really look like a fork.
|
|
|
|
|
I heard they had a major accident a few years ago, during which most of the bodies were lost (defrosted).
Oops.
The idea is not bad otherwise. It's just hard to fulfil the promise of keeping something up and running for what is most likely at least a century.
|
|
|
|
|
Show Posts
