Here's old tech, that can work over about any fidelity including phone as long as there aren't wholesale dropouts: http://en.wikipedia.org/wiki/Kansas_City_standardIt uses two tones: one cycle of 1200hz = 0 bit, two cycles of 2400hz = 1 bit. This is 1200 baud, so it's going to be good for things like an audio address exchange, not for 10MB of data. One could use different frequencies for full duplex signaling (ie the receiver could send "ready to receive your transmission" or "error, retransmit" messages with 1700/3400hz audio). Sounds like this: basicode.wav. Here is an encoder/decoder written in Forth for the original 300 baud version: http://www.netbay.com.au/~dxforth/#kcsHere's one in perl: http://www.cse.dmu.ac.uk/~mward/martin/software/index.html#CUTSThis is very easy to program for sending data. Just make a LUT of the two waveforms, and dump the data out as a 12KHz sampling rate wav. For reading the data, you will need a simple fft able to discriminate which is the dominant tone and a transition-following clocker. For actually coding, one would look at simple coding like RLL, with words encapsulated with ECC or sequence numbers. Data could be packetized into IP MTU-sized packages. One must remember how slow even the height of v.90 modem tech was - it would take 20 minutes just to download this web page. Hold your phone up to your computer speakers to transfer data... |
|
|
|
Hey since when I get different lucky numbers for one transaction (2 bets)  Since Jan 3: At 2013-01-03 00:00 GMT (In about an hour) the logic for calculating the bet hash which was hmac512(secret, bet_transaction_id) will be changed to hmac512(secret, bet_transaction_id + ":" + bet_output_index)
This means that each bet inside a single transaction will get a different lucky number. With this change, we will be relaxing some of our max check logic so that players will be able to make multiple bets to the same address in a single transaction.
Currrently, if a player sends a transaction of:
{
250 BTC -> 1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE
250 BTC -> 1dicec9k7KpmQaA8Uc8aCCxfWnwEWzpXE
}
The first one will be processed normally, the second one will be considered above max.
At the switch over at 00:00 the same transaction will be processed as two separate bets with two separate lucky numbers and won't be considered above max.
I'll be updating the docs to reflect this as well.
Correct. And this was done because players could stack bets together in one transaction to effectively get over the bet max. This wasn't "unfair" to anyone, but it did cause very high variance that was quite risky for the house to run. It was decided to ensure each input got its own lucky number, but then also increase the max-max bets up to 500. So high rollers should be happy still, but the system is more stable/less volatile. There is a larger max payout now on single bets than combining many bets previously if you look at exchange rates. This max transaction Jul 10 $11.66-> $39,200 on 0s Today: max bets at 1000x-64000x: $1.13-$72.50 -> $72,400, so the house has a higher bankroll and we assume this won't break them. One in a million chance that two bets pull out $140,000. |
|
|
|
|
More important, are you planning on having it give correct results?
0.056729178 is the Bitcoins per day I calculate using the screenshot's inputs. The calculator doesn't know about the block reward halving.
Most miners pay a pool fee as a percentage, let them put that in and they will get more accurate results.
If you are using mtgox's exchange rate, you might as well take out mtgox's 0.6% cut too.
The average length of a month is 365.2425/12... your results shows ~365.2088/12 but that might just be rounding errors.
|
|
|
|
I was initially making a number of bits (yes, a single 256-bit number, known in JavaScript as NaN), where the probability of a bit being set was based on a ratio, however "true randomness" could let the OP cheat so I had hacked a check loop on.
Yes, but that is not going to work because the OP can just keep generating until he gets one that favors him, and only THEN reveal it. Please re-read my sentence. One sentence isn't too much to comprehend before posting. Finish reading until the end. My second posted code only gives fair results. I added checking because I saw within minutes (not two months later) and addressed such a possibility for cheating: I tweaked the code so only a secret grid with an equal number of 0 and 1 bits will be used (only about 1 in 20 will have an equal number). Otherwise the operator may search for one with bias.
The script also creates a unfalsifiable hash that can be published before gaming begins: You post the SHA256 now so we can later verify the real secret "grid" was used. The coding was just an example to show in comparison how preposterous, naive, and unprovable the original poster's game proposal was (bet against his unpublished Excel spreadsheet). Getting either a working Python environment or being able to do something with your JavaScript snippet are both tasks likely out of his depth. |
|
|
|
|
I was considering this, but then I read the Dwolla terms of service:
Authorizations for Chargeback:
You understand that Dwolla does not warrant the transactions and that these transactions are subject to ACH chargeback processes. You agree and warrant that any chargebacks received by Dwolla can and will be debited from your Dwolla account and if such funds do not exist a debit for the chargeback amount will be placed against the bank account to which the funds were withdrawn.
Reversals
The party receiving funds in a transaction may be subject to reversals occurring within the account if claims are made by the sending party or by the sending party's financial institution.
You understand and agree that:
● If there is a reversal of a payment to you, you will be liable to Veridian for the full amount of the reversed payment plus a fee in the amount of $15 ("Reversal fee"). The reversed payment plus the reversal fee is the "Reversal Liability."
● Reversals are debited by Veridian in the Veridian Holding Account and will be reflected in Your Dwolla User Account.
● If You do not have a balance in Your Dwolla User Account that is sufficient to cover Your Reversal Liability, the remaining balance in Your Dwolla User Account (if any) will be used to cover the Reversal Liability, and You authorize Dwolla, acting on behalf of Veridian, to take any of the following actions:
1. Debit your attached Bank Account in the amount of the unpaid portion of the Reversal Liability;
2. Suspend Your User Account and require you to take immediate actions to repay the unpaid portion of the Reversal Liability; and/or
3. Engage in collection efforts to recover the unpaid portion of the Reversal Liability.
And some cream:
You understand and agree that Dwolla is not responsible for any losses or liability resulting from actions taken against Your User Account as detailed in this section.
|
|
|
|
The house edge isn't guaranteed income. The actual profitability of a gambling site goes up and down dramatically. The smaller the house edge, the bigger the chance of them being unable to pay out their winning players. The bigger the house edge, the bigger the max bet they can safely offer. You don't want to be playing on a site with a 0.01% house edge because they'll eventually go bust, and be unable to pay you out when you win.
Oh, you are right. But this theory is true only for games against the house. And it is up to the player to choose to play with the negative EV and get results immediately or to play on the P2P betting exchange with zero EV, but get results later when there will be another player to match the bet. Threadcrapping while advertising your own gambling site in your sig: welcome to my ignore list. |
|
|
|
Transactions either require a fee (because they are small or the coins aren't aged long enough) or they don't require a fee. Any analysis of fees should take into consideration (and discount) satoshidice transactions, as they are generally a house-of-cards, where one transaction relies on previously relayed coins that have no confirmations, these will languish until the original transactions are confirmed regardless of fee included. For example there is a transaction that has paid double the required fee but has not been included because it is funded by several other transactions which are also not confirmed. The inclusion of "free" transactions in blocks is up to miners (pools). Here is some of the parameters a pool can alter without needing to alter the Bitcoin client: -blockminsize=<n> Set minimum block size in bytes (default: 0)
-blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 27000) We should first look at how Bitcoin handles transactions that require a fee but don't include it (which can only be sent with an altered Bitcoin). The parameter "minimum block size" is a default value of zero, meaning no transactions not including the minimum per-kb fee will be included. If this is raised to a much higher value by a pool, this means that even spammy free transactions can be included anytime the block is smaller than this minimum after including all normal transactions. No pool I know of alters this (without some further code changes) because it just provides a free way to spam the blockchain with no benefit to anyone but the sender. Only pools like Eligius allow for some free small transactions, using their own rules, transactions that other Bitcoin peers generally won't even relay. Then lets examine how transactions that qualify to be free are handled: there is a "free transaction" window of 27KB (of a maximum block size of 500K). This is what makes high-priority transactions free. However, they must still compete for just a small part of a block with other high-priority transactions, ranked in order of priority, but this space reserved for high-priority transactions is rarely full, meaning that high-priority non-fee transactions are almost always included in the next block. The Bitcoin client doesn't even prompt for a fee when sending a high-priority transaction. Finally there are normal transactions, these are ones that pay at least the minimum fee as required. As of 0.7.0 (when run by a pool), they are sorted by fee, so that ones that pay more than the required fee are ranked more highly than minimum-fee-payers. This "paid" area also can include high-priority transactions that have volunteered a fee. In conclusion, one must properly analyze all available information about a transaction (priority, size, time relayed, funding source) before evaluating the effectiveness of paying more fees. However, one can simply examine the default rules of Bitcoin to determine if volunteering more fee is of benefit. |
|
|
|
|
If it's really just a media center only, you don't need much. I had an Athlon X2 7750 2.7GHz system 1GB that decoded blu-ray and ATSC just fine.
|
|
|
|
Thank you, why these people don't learn the difference between written and spoken Japanese is beyond me. 外題学問らしい |
|
|
|
Apparently the drive plug is just a longer version of SATA+power to fit through the thickness of the case. You can gut $3 amazon USB 2.0 cases, or buy a rubber case like this one and cut a connector hole through it so the connector will appear to sit flush while making a bare drive less likely to short out on something. |
|
|
|
Mike, is it possible to buy a batch of coins, then resell them and have them funded only after the customer receives them? This could be done in batches of course. Maybe weekly or in batches of 10 coins to reduce your workload.
This would simplify shipping and reduce risk.
This is undesirable, as then untampered but unfunded coins could be in circulation, making the whole coinage untrustable. This is a previously posited perfunctory purloining procedure. |
|
|
|
URL: https://github.com/bitcoin/bitcoin/pull/21001) Create COIN_DUST constant, to represent the dust spam limit used. 2) Update COIN_DUST from 0.01 BTC to 0.001 BTC Rationale: With the increase in bitcoin value (US$13.67 as of this writing), it seems reasonable to reduce the value level of which we consider "dust spam." When the minimum fee (if a fee is even required) was reduced 20-fold from .01 to .0005 (and the exchange value was doubling every month) in May-June 2011, the value of Bitcoin was the same as today. This greatly impacted the economics of Bitcoin as set up by Satoshi - upon examination of any facet of the currency, everything about Bitcoin seems extremely thought out as though it was delivered through divine intervention. Using a similar "value" argument to also allow more small transactions for free doesn't quite hold up. If you really want to send 0.005 today, you can for a 10% fee (Paypal would charge about a 700% fee for someone to receive $0.05 from you). A fee of less than $0.01 to instantly send any amount of money anywhere in the world is pretty reasonable. |
|
|
|
|
I would suggest no free work be done for the OP until the alleged coins from the noob are held in escrow and the terms of the nonexistant "name competition" are completely disclosed.
|
|
|
|
Wow, really? Some JS:
var gridSize = 1024;
var bits = 512;
var assignedBits = 0;
var grid = [];
while(assignedBits < bits){
newLoc = Math.floor(Math.random() * gridSize);
if(!grid[newLoc]){
grid[newLoc] = 1;
assignedBits++;
}
}
No need for floats or anything.
Wow, really? Some Python (that produces output):
import random;s=1024;b=512;g=[1]*b+[0]*(s-b);random.shuffle(g)
for i in range(0,s,16):print '{0:4d}:{1}'.format(i,g[i:i+16])I was initially making a number of bits (yes, a single 256-bit number, known in JavaScript as NaN), where the probability of a bit being set was based on a ratio, however "true randomness" could let the OP cheat so I had hacked a check loop on. |
|
|
|
  Hi-res source files (with transparent background): White text (dark shirt) two color:  Black text (light shirt) three color:  Released into the public domain. |
|
|
|
Some talks from the 2012 East Coast Bitcoin summit: http://www.youtube.com/playlist?list=PL-sagavSvMdMBK36FBIfnVupeJdt_lMi5When watching several, I thought of ways that 60 minutes could be turned into five with a proper script and complementary animated graphics. The problem is the conference is guys reading a slideshow of topic words to you and ad-libbing between. The problem with documentary videos is that it is just words being read at about 1/3 the speed you can read them yourself, with pictures that are often irrelevant. Critically look at most Discovery Channel style documentaries where topics like "brain activity" or "the creation of the universe" or "Ben Franklin went to France" are throwaway irrelevant stock animation playing on a loop or B-Roll archive shit while an announcer says nothing slowly. If you look at the script (or closed caption dump) of a typical documentary, it's about one page. |
|
|
|
|
The solution above was the best post I had for removing newer drivers' OpenCL files and installing a driver with a working OpenCL (installing a seperate SDK is not required unless you are doing other unrelated things like building libraries from source). Many posts in this thread, even in the last few pages, indicate the same answer regarding newer drivers not working. As above posters noted, disregard the last line about underclocking RAM - for vanitygen, increasing GPU clock and RAM clock to their maximum independently will both boost address creation rate.
|
|
|
|
Compiling kernel, can take minutes...failure.
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
calclCompile failedError: Creating kernel ec_add_grid failed!
Device: Caicos
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1016 (VM)
Profile: FULL_PROFILE
Version: OpenCL 1.1 AMD-APP (831.4)
Max compute units: 2
Max workgroup size: 256
Global memory: 1073741824
Max allocation: 536870912
Available OpenCL platforms:
0: [Advanced Micro Devices, Inc.] AMD Accelerated Parallel Processing
0: [Advanced Micro Devices, Inc.] Caicos
1: [GenuineIntel] Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz
Win7. Any ideas? You've got a video card that's $14.99 after rebate? Do what this post says. |
|
|
|
|
Show Posts
