|
Ok, so first, I did not create this thread, Theymos did.
Concerning the deleted post, I quoted a number of especially trollish statements to the effect that the "end is nigh", because, you know, Bitcoin Foundation. And noted how the quoted segments fit the definition of trolling ecactly. I then (stupidly perhaps) embedded a GIF saying don't feed the trolls. I guess trolling is okay, but recommending that people don't feed the trolls is not.
Mea culpa.
Concerning the edited post: Theymos, are you able to figure out who blanked out the link(s) in my post?
Lastly, since this is now apparently in META:
May I suggest that one should receive an automated notification upon being moderated,
so that people can actually learn from their transgressions?
One should know what has been moderated, and when.
The reason for being moderated can be omitted, so as not to add to the burden of the moderators.
Preferably, the offending post should be visible to the poster, mods and admins only.
|
|
|
|
First, you edited my OP and broke all of the links changing .org to .com.
Then you sent me a PM asking if it would be ok to move this thread to Service Discussion. WTF? If discussion of the Foundation isn't a good topic for the main Discussion forum what is?
Woah. That is a significant abuse of moderator power. Has hazek edited any of your other posts? Has hazek edited any of my posts? Has hazek edited any of satoshi's old posts? Editing another's posts is far worse than deletion, when it comes to abuse of moderator powers. That is misrepresenting someone else's identity. First, I had one of my posts (which was friendly to the Bitcoin Foundation) deleted. Second, and more curiously, one of the links in this post was changed (not by me) to simply: "http://" Since I received no notification of my posts being edited/deleted or otherwise moderated, my first thought was that perhaps my account had been hacked.  |
|
|
|
|
But this shows that Bitcoin is currently more ameripean than global.
|
|
|
|
Can you please change "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" "$1" into "C:\Program Files (x86)\Bitcoin\bitcoin-qt.exe" "%1" and report back! Changed the "$1" part of the registry value to "%1". Works fine now. I believe I upgraded to 0.7 from 0.6.2. Possibly from 0.6.3. (Not from an RC version.) Would forcing the registry value to "%1" during installation break anything? Thanks for the help.  |
|
|
|
FUCK This is bad. Real bad.  Why? 5 blocks in a row and appearing fully legit. False alarm. See the last post in that thread. |
|
|
|
Is there a reason you're answering questions there are opposed to here?
Uhh, have a look at the announcement thread. Yeah. There's a reason. |
|
|
|
Well I was wondering how long it would take for people to notice. It's me
And no I am not putting lots of hashing power to the network, notice that it just says "relayed by" and not "mined by". I'm performing some measurements, paper is due in a few weeks.
Cool. Well, today I learned a bunch of arcana about relaying versus mining blocks. What, exactly, are you measuring? How many people are grappling with Bitcoin at ETH Zürich?
thank you! due your work I came under attack of some moderators and some pool operators (which I really like!)
Well that's a weird way to look at it. They happened to be right, and we happened to be wrong. There is not much honor in being a fool, but there can be some merit in admitting the mistake. Now, what we should do is learn from the experience, and only then feel good about ourselves. |
|
|
|
I disagree. This whole article seems speculative, like it admits towards the end. There can be price rise without volume rise, only after some time this trend becomes validated by a rise in volume or it collapses if no volume rise sets in. The premise price>follows>volume is not (always) true. Also I fail to see how some "Volume Cycle Sequences" needs to be completed before a trend change can happen. If you take a look at historic charts (e.g. the Jan '12 to March '12 period in total) no "Volume cycles" are completed and yet the trend changes.
@ OP: Nice visualization of volume patterns! I couldnt have put it better. The peaks always seem to confluence with early evening hours of the US East Coast. Too bad I have to stay up so long to catch that time frame from where I am (Germany) :X
Yeah, I quoted this mostly because it was so damn bold. (And hence, very likely wrong.) Any statement of the form: The market...always...something will always be wrong. (At least once, and likely often.) |
|
|
|
|
I will pay 100 bitcoins for a valid proof (or disproof) of the Riemann hypothesis.*
*Since this is contract work, I will retain copyright to the solution in the capacity of being your publisher,
|
|
|
|
Their public http server has a file named BitThief.exe
Wallet stealer? I believe BitThief was shown to be non-bitcoin related. |
|
|
|
Post count of 13? Who are you and why should we care?
Uhm, post count is worse than useless when it comes to the validity of an argument. If anything, post count on Bitcointalk often seems to be somehow inversely related to common sense, intelligence, and verbal ability. Therefore, the more you post, the dumber you get. (I'm mostly joking. Mostly.)  Also, this wouldn't be a first. Or second. MtGox in July 2011 was the first. Bitomat was the second. Everyone who lost money in those two cases was made whole.
MtGox had the more than enough revenue to make everyone whole. Bitomat was bought out by MtGox as an act of good faith. Bitfloor doesn't have nearly enough revenue, and MtGox is not going to buy them out. It seems to me that your objection is quite irrelevant to Bitfloor hostage situation. |
|
|
|
So let me get this straight? They're not trying a sustained 51% attack...that would take too much power. Instead they're running at about 8-9% of the network, and hoping to get 6 blocks in a row to reverse a transaction (double spending)?
http://bgp.he.net/ip/82.130.102.160ETH Zürich have been experimenting with fast double spend attacks, and is currently (as of today) bringing massive mining power to bear on the main network. Their public http server has a file named BitThief.exe on it, and they're spamming ping messages. (Denial of Service?) Did i miss anything? |
|
|
|
Reading their paper, it seems that their goal is to send coins to one address, but after that confirm a spending of the same coins to their own address by their miners.
One should note that the "Fast Double Spend" paper has already been submitted to, accepted by, and is due to be presented on the ACM CCS 2012 conference in about two weeks. So: Whatever they are doing now, it is not related to that specific paper. |
|
|
|
http://bgp.he.net/ip/82.130.102.160ETH Zürich have been experimenting with fast double spend attacks, and is currently (as of today) bringing massive mining power to bear on the main network. Their public http server has a file named BitThief.exe on it, and they're spamming ping messages. (Denial of Service?) Did i miss anything?
|
|
|
|
Unless you have 51% of the whole network's hashing power right?
No, it's still exponentially difficult over larger numbers of blocks. (Page 8 in the Satoshi whitepaper) Edit: I may have been wrong about this.The Bitcoin whitepaper doesn't discuss cases where the attacker's mining power is above 0.3 By Satoshi's analysis, doesn't it get exponentially hard for honest miners to catch up to an attacker, if the attacker controls >50% of mining power, not just blocks solved? Haven't thought much about majority attack feasibility before today.
Thankfully: "[2] In our experiments, we solely used Bitcoin wallets and
accounts that we own; other Bitcoin users were not affected by our experiments."
These guys didn't steal anyone else's money. But there is a flip side to that coin. |
|
|
|
I dont know whether they mine with full power yet, but its not 51%, its 8.547% actually.
Number of Blocks relayed by 82.130.102.160: 20
First block relayed at Blockheight: 200691
Current Blockheight: 200925
dBlockheight=200925-200691=234 -> they have competed for 234 blocks yet
20/234*100%= 8.547%
They have currently relayed 8.547% of all blocks they have competed for.
what is the timeframe for an 51% attack. 6 blocks? , maintaining a supermajority attack gets exponentially hard over n-blocks. Hence: "Double-Spending Attacks on Fast Payments in Bitcoin" |
|
|
|
Swiss... they have something to defend
Yes. Bitcoin is the new Swiss Bank Account. This is not a bad thing. That is a legitimate organization, they are not doing it with hostile intent. Very interesting though!
Of course ETH Zürich is legitimate. However, they could still be Bitcoin hostile. It's a relief to see that this is a research operation. I'd be rather more concerned if this was an unidentified organization with unknown intent. I was quite astounded to discover that their group (or indeed any organization) was able to roll out enough mining power to find 7 blocks in 70 minutes. Pretty impressive, if it's just for a feasibility experiment. |
|
|
|
... Until now, double-spending attacks on fast pay-
ments in Bitcoin or mechanisms for their prevention
have not been studied. In this work, we analyze
double spending attacks in detail and we demon-
strate that double-spending attacks can be mounted
on currently deployed version of Bitcoin, when used
in fast payments. We further show that the measures
recommended by Bitcoin developers for fast trans-
actions are not always effective in resisting double-
spending; we argue that if those recommendations
are followed, double-spending attacks on Bitcoin
are still possible. Finally, we propose a lightweight
countermeasure to detect double-spending attacks in
fast transactions.
More specifically, our contributions in this paper
can be summarized as follows:
We measure and analyze the time required to con-
firm transactions in Bitcoin. Our analysis shows
that transaction confirmation in Bitcoin can be
modeled with a shifted geometric distribution and
that, although the average time to confirm transac-
tions is almost 10 minutes, its standard deviation is
approximately 15 minutes. We argue that this hin-
ders the reliance of transaction confirmation when
dealing with fast payment scenarios.
We thoroughly analyze the conditions for perform-
ing successful double-spending attacks against fast
payments in Bitcoin. We then present the first
comprehensive double-spending measurements in
Bitcoin. Our experiments were conducted us-
ing modified Bitcoin clients running on a hand-
ful of hosts located around the globe. Our results
demonstrate the feasibility and easy realization of
double-spending attacks in current Bitcoin client
implementations.
We explore and evaluate empirically a number of
solutions for preventing double-spending attacks
against fast payments in Bitcoin. We show that the
recommendations of Bitcoin developers on how to
counter double-spending are not always effective.
Leveraging on our results, we propose a lightweight
countermeasure that enables the secure verification
of fast payments. ...
|
|
|
|
http://www.syssec.ethz.ch/research/BitcoinDouble-Spending Fast Payments in Bitcoin This site is under construction.
Update 1:CCS 2012 19th ACM Conference on Computer and Communications Security Oct. 16-18, 2012, Sheraton Raleigh Hotel, Raleigh, NC, USA http://www.sigsac.org/ccs/CCS2012/techprogram.shtml Double-Spending Fast Payments in Bitcoin Ghassan O. Karame (NEC Laboratories Europe), Elli Androulaki (ETH Zurich), Srdjan Capkun (ETH Zurich) Update 2: Found it! http://eprint.iacr.org/2012/248.pdfReading the paper now. Update 3: Abstract Bitcoin is a decentralized payment system that is
based on Proof-of-Work. Bitcoin is currently gaining
popularity as a digital currency; several businesses
are starting to accept Bitcoin transactions.
An example case of the growing use of Bitcoin was recently
reported in the media; here, Bitcoins were used as a
form of fast payment in a local fast-food restaurant.
In this paper, we analyze the security of using
Bitcoin for fast payments, where the time between
the exchange of currency and goods is short (i.e.,
in the order of few seconds). We focus on doublespending attacks on fast payments and demonstrate
that these attacks can be mounted at low cost on
currently deployed versions of Bitcoin. We further
show that the measures recommended by Bitcoin developers for the use of Bitcoin in fast transactions are
not always effective in resisting double-spending; we
show that if those recommendations are integrated
in future Bitcoin implementations, double-spending
attacks on Bitcoin will still be possible. Finally, we
leverage on our findings and propose a lightweight
countermeasure that enables the detection of doublespending attacks in fast transactions.
|
|
|
|
|
Show Posts
