Feature request: Multiples of VIR. Since there is often more supply than demand at VIR, it would be nice if you could offer at say 0.8 times VIR.
VIR plus or minus a percentage would make sense, like banks do with "prime rate". With the volatility of VIR, that could lead to negative rates... |
|
|
|
|
Feature request: Multiples of VIR. Since there is often more supply than demand at VIR, it would be nice if you could offer at say 0.8 times VIR.
|
|
|
|
|
Tried to do this. Price increased. Permanently. I think the trend is comparatively strong compared to the noise.
|
|
|
|
|
I am a Sharkbullpig. Loan shark.
|
|
|
|
|
I just hope they volume weight the price over some period for the settlement price. Otherwise manipulation is just a question of time. And then, worst case scenario, there will be people not sharing the BTC values shouting for TPTB to baton the manipulators.
|
|
|
|
Dear Customers
...
Giancarlo
Customers Relations
Bitfinex Team
This is very positive news! |
|
|
|
|
This was entertaining to watch
|
|
|
|
Seems like a nice way to artificially reduce the network hashing rate / temporarily split the network.
I use a number of nodes to send 2 transactions spending the same input to the network, but I make sure to send them as close as possible to the same time. Thus, the rest of the network see that there is a double spend, but there isn't a strong consensus as to which order the transactions arrived, so half the network mine a fork with one transaction and the other half mine a fork with the other. At some point in the future, one side decides it must have been wrong and one of the forks wins. Up until that time, each fork has been competing possibly with many reorgs.
That's for a single double spend. Now think about a collection of nodes which continuously pump out double spends. Each split halves the hashing power if perfectly timed, it doesn't take much to bring the network to its knees.
Nice attack, but it can be protected against. If 2xspend are close together ( <10s), try to mine a block with the earlier transaction. Do not penalize chain choosing the later transaction If 2xspend are sent far apart ( >10s) try to mine a block with the earlier transaction. Penalize chains incorporating the later transaction. Now if they are sent close together the network will not split, but the fraud will be detected in time. If they are sent far apart, all nodes will try to favor the earlier tx. If you try to send some nodes <10s and some > 10s, then they will all be able to get the earlier tx before the later, since it will have time to propagate. Hence this will not split the network either. Your Proposal does not protect against that attack. What if i sent the second Transaction after a specific time, so that it reaches half of the Network <10s appart from the first Transaction and the other half of the Network >10s appart from the first Transaction? It does. Maybe I didn't explained it clearly. Lets look at what happens Attack goes like T=0 Transaction 1 sent to Miner group A T=2 Transaction 1 sent to Miner group B T=11 Transaction 2 sent to everyone What will also happen T=6 (ok I am just guessing the this happens. Important thing is that it should be < T=11) Miner group group A forwards to group B Since at T= 11 everyone will have heard about Transaction 1, it will be the one included. |
|
|
|
Seems like a nice way to artificially reduce the network hashing rate / temporarily split the network.
I use a number of nodes to send 2 transactions spending the same input to the network, but I make sure to send them as close as possible to the same time. Thus, the rest of the network see that there is a double spend, but there isn't a strong consensus as to which order the transactions arrived, so half the network mine a fork with one transaction and the other half mine a fork with the other. At some point in the future, one side decides it must have been wrong and one of the forks wins. Up until that time, each fork has been competing possibly with many reorgs.
That's for a single double spend. Now think about a collection of nodes which continuously pump out double spends. Each split halves the hashing power if perfectly timed, it doesn't take much to bring the network to its knees.
Nice attack, but it can be protected against. If 2xspend are close together ( <10s), try to mine a block with the earlier transaction. Do not penalize chain choosing the later transaction If 2xspend are sent far apart ( >10s) try to mine a block with the earlier transaction. Penalize chains incorporating the later transaction. Now if they are sent close together the network will not split, but the fraud will be detected in time. If they are sent far apart, all nodes will try to favor the earlier tx. If you try to send some nodes <10s and some > 10s, then they will all be able to get the earlier tx before the later, since it will have time to propagate. Hence this will not split the network either. |
|
|
|
as marginalized and shunned as, say, drugs or porn today.
That doesn't sound so bad... |
|
|
|
What struck me as interesting is how the Bible has been commonly used throughout history as a propaganda tool. If there was a Korean sect of Christianity, I wonder if there would be a Korean Jesus.
"The 2005 South Korean census showed 29.2 percent of the population as Christian" The more you know.. |
|
|
|
The problem is that it isn't up to us. There is no "we".
There is a "we". We who want BTC to be usable as a you know, currency. No one on the entire planet has the ability to prevent miners from picking transactions according to their own criteria. We can change their incentives. Bubbleboy posted a very nice proposal. See: https://bitcointalk.org/index.php?topic=180640.0 |
|
|
|
|
Retail will want transactions satisfying:
Time to verify: < 10 seconds
Risk of charge-back/double spend: < 1%
If we change 0-conf double spends from possible to trivial, it will no longer be possible to satisfy those constraints with bitcoin.
|
|
|
|
|
If thinking like this starts creeping in than we are on a slippery slope. Why not reverse a 1-Conf transaction, if the pay is good? I think we should try to nip it in the bud. Encourage good behavior by orphaning transaction reversal blocks.
|
|
|
|
|
-1 on this idea.
Also bribing miners to replace a TX is a horrible precedent.
|
|
|
|
...
Do you see any conflict of interest in both trading on, and working for bitfinex? |
|
|
|
|
Willing to take bear part of
A=24
B=100
X=1
Y=1.2
(well actually X=0.5, Y=0.6)
EDIT: Offer valid for one hour from now.
|
|
|
|
Hi there,
I'm curious if anyone has a dataset with historical USD/BTC rates/volumes at a high level of granularity. I'm going to be working with Bloomberg to pipe-in Mt.Gox data but would like any and all inputs in terms of ideas, alternative exchanges to include, and any heads up you may have to those that have attempted to do something similar previously.
Thanks,
Makksik
Proof of concept: Integration of CADvirtex on Bloomberg. Gotta study for a final tomorrow... Update you guys later. All Bloomberg Technical Studies can be run (RSI and BOLL on example snap). Will try to integrate every exchange at full granularity and release to the public over the weekend.  I suppose this is a buy signal? |
|
|
|
|
Swede, registering interest.
|
|
|
|
|
Show Posts
