Thanks for the follow-up.
Maybe I'm a bit simple minded, but I do not see how this directly correlates to the BTC USD exchange rate.
I do appreciate the info, however.
Visa handles, at peak, ~4000 transactions per second. With Bitcoin, there are multiple solutions, but none of them involve doing nothing and continuing to use the blockchain alone: - Move most transactions off-chain - Increase MAX_BLOCK_SIZE - Increase blocks per day - Make smaller transactions somehow |
|
|
|
I've got no horse in this race, but I believe BTC's max is currently 7 T/S
Follow-up question -- why is there a 7 transaction/s limit? 10min blocks* -> 6 blocks / hour (6 blocks / hour)(1 hour / 3600 seconds) = 0.0016667 blocks / second Max block size = 1 MB(0.0016667 blocks / second)(1 MB / block) = 0.0016667 MB/s (0.0016667 MB / second)(1,000,000 bytes / 1MB) = 1666.7 bytes / second According to dooglus, there are (in*148 + out*34 + 10 plus or minus 'in') bytes in a transaction. This equals a minimum tx size of 180 bytes, and a 1-input 2-output minimum size of 225 bytes. Example. (1666.7 bytes / second)(1 tx / 180 bytes) = 9.26 tx/s (1666.7 bytes / second)(1 tx / 225 bytes) = 7.41 tx/sMost transactions are bigger, so these are high estimates. *Note that an ever-increasing hashrate (like the current scenario) means blocks are generated faster, on average, than once every 10 minutes, and a decreasing network hashrate would slow block creation. This is due to the fact that difficulty is only calculated periodically (every 2016 blocks). |
|
|
|
|
You're incentivizing people to make 50 posts per day?
|
|
|
|
In Objectivist-C, there are not only properties, but also property rights. Consequently, all properties are @private; there is no @public property. This one got me  In Objectivist-C, all objects can be subclassed. Objectivist-C cannot be compiled by a libertarian compiler. |
|
|
|
I have a doubt about the construction of the operation and confirming the information on the Trezor.
The images and videos I saw so far show that Trezor displays the address you send money to and the amount you send, but there are several things in that transaction that a malicious client (modified by an attacker) can modify and I need to review in the Trezor in order to accept the transaction.
My doubt is, how do I know when signing on the Trezor that the fee is not incredibly high or the change address is not mine (attacker redirecting the founds to another address)?
I think, and hope that Trezor would display all inputs and all outputs I'd hope for Trezor to spit out the signed raw transaction, without the computer automatically publishing it, so you can decoderawtransaction just to make sure. Of course the software would display it in a very user-friendly way, so the grandmas wouldn't have to actually use the debug console / bitcoind. |
|
|
|
EDIT: Also, r3wt was previously banned more than a month ago for spam on coinchat. He came back under the name "Nimda" So that's why...! Bastard... |
|
|
|
|
Assuming you live in the US, you can legally get certain jobs at 14. Whether or not there are actually jobs available will depend on where you live.
|
|
|
|
I'm open to different interpretations, though.
With about as much seriousness as 1/3 of a duck: BFL was incentivized by the donation offer. This caused them to expend significantly more resources (valued at almost $200) to ship faster. (You might not believe it, but they were going to ship later) Without this timely donation, harm has been caused to them (see value above) by Phin's broken promise. Broken promise (fraud) + monetary damage = scam!!!1  |
|
|
|
By the time you actually win, the betting pool would look something like 12k BTC at least. Unless of course you are extremely lucky and win in a few play.
100% of profits are paid out to shareholders. How the betting pool is funded mid-month is unclear. |
|
|
|
|
Again, not a shareholder, but S.DICE holders might wish to know:
Eric stated that the betting pool was 6100 BTC.
The lessthan 64 bet has a payout of 999.429x and a max bet of 6.4100 BTC.
999.429 * 6.4100 = 6406.33989
6406.33989 > 6100
That is all. Draw your own conclusions. I am not a laywer or broker, and this is not financial advice.
|
|
|
|
Welcome to dramatalk, where the scammer tags don't matter and everything is illegal  I want to thank Phin for always being absolutely ridiculous in his characteristic deadpan manner. I imagine if held at gunpoint, he would begin to talk about some failed deal involving 3 laptops and half a duck. |
|
|
|
Everyone it seems in agreement. Yes its possible but no, it's so unlikely there is no need to worry about it. OK but wouldn't it be fairly simple to have an automatic check within all the clients and a simple prompt .. 'this key pair already exits please try again' Getting Deja-vu on this topic but its nice to rehash once in a while.  It would be better if it said "Bingo! You've found someone else's address -- transferring all their funds now" And then told you, "Due to the incredibly small chance of this happening naturally, this event probably represents a fundamental flaw in the way Bitcoin addresses are generated. Sell all your coins and warn your close friends, then notify Gavin Andresen." |
|
|
|
Another question - backing up the address book. How do I do that. Couldn't find an obvious address book file.
The address book is, uh... in messages.dat. Don't ask me why. As for upgrading with git, you can "pull" or you can "fetch" and "merge." |
|
|
|
Woah, dooglus, you're making a dice site?   Not sure I like the secret-in-url idea a la instawallet... |
|
|
|
I remember when they used to say the highest bandwidth connection was a station wagon full of tapes on the highway.
For large amounts of data, SSDs on a plane is still more efficient than the Internet. |
|
|
|
|
On the other hand, what does the OP stand to gain from lying? Sympathy tips?
|
|
|
|
|
Note: While academically interesting (I hope), this is not applicable to Bitcoin without a hard fork.
The current problem of transaction spam is thus: miners collect the fees, but every full node must pay the cost of increased storage. There is, however, an elegant solution to this problem, which disincentivizes large (as in bytes, not value) transactions.
Require that each transaction destroy a small fraction of the currency unit. As satoshi himself said, lost coins are like a "donation to everyone." If the currency used floating-point or some other, non-atomic method of measuring value, this could continue indefinitely. A transaction could be considered invalid unless it destroyed some amount of currency, either directly proportional to, or exponential to, the size of the transaction itself.
This system would obviously reward those with higher balances more than those with low balances; however, it might be better than the current system, in which miners are incentivized to mine most fee-carrying transactions, regardless of the cost to the thousands of full nodes.
Another problem would be the high rate of deflation: a system like this would probably be more prone to a "deflationary spiral" than Bitcoin currently is. Making it work would require striking a difficult balance.
Thoughts?
|
|
|
|
|
Show Posts
