Woohoo. I got it. I started with this paper and software and patched it to support the secp256k1 curve. It is slow as hell, so I think it is doing the multiplication the hard way, but it works. |
|
|
|
Had a storm last night and the damn power went out. Problem is I can't get to the rig and get it going again until 8pm my time (9:35 now).
This happend to me too once. Now I'm running vpn on router and I enabled Wake-On-LAN on rigs, so I'm prepared next time. That's not a bad idea. I have have two psu's running my rig (on is piggy-backed on for 2 of the gpu's), so it wouldn't work for me.  I just have all my hardware set to automatically start after a power failure. And I have 1 rig that has two PSUs, but both PSUs are tied into the 24 pin motherboard connector (using a splitter) so that they both turn on and off with the computer. Personally, I prefer to use a relay on one of the molex connectors to trigger the second power supply. But now that dual power supplies are more common, it is nice to see premade splitters so that people don't need to cut and splice their gear. |
|
|
|
perhaps you'd be able to power them on, but it is a two-way session and you are going to have to get a signal from the 5mm (wild ass guess) antenna inside the card back to you reader. gl w/that besides, canada uses chips already on their cards (at least for debit) that require you to put the card physically in a machine. not a big stretch to think that they might use the same system here Quite the opposite, actually. Getting power into the inductor to activate the chip is the hard part. Eavesdropping on the RFID handshake from dozens of feet away is easy. And when I say "easy", I mean don't take your RFID tags to Vegas when Defcon is in town. |
|
|
|
I'm going to assume it's exactly like the Visa/MC chips where it generates a unique handshake per transaction and somebody standing 10ft from you holding a RF reader bought from ebay can steal your coins and spend them without you ever knowing.
you need to be about an inch away but otherwise 100% accurate |
|
|
|
Why would the new node include the orphan coinbase in the next block?
Similar question: Why would a miner include a transaction without fees? As far as I know we have no answer to that one as well. Still the algorithm works. Also you are rewarding non security. Block height = security. Parallel blocks don't increase security. We want miners to be competitive to minimze wasted hashing power. You aren't throwing out work you are throwing out duplicated work.
Do we have a formal, mathematical proof for that? Do we have comprehensive, published experimental test results which show this? If yes, I would like to learn where to find them. Please point out some sources or references so that I can study them. A formal mathematical proof that X+1 is greater than X? Definitions don't need proof. |
|
|
|
It is possible for people create non-fraudulent double-spends. A common case: if they forgot to include a sufficient fee and the transaction goes into limbo, they can resend it with a fee. Under this proposal there's a small chance they could lose the entire balance if a miner who considers the no-fee transaction to be valid and then mines them both. Evil miners could even hoard such transactions hoping for the opportunity to confiscate a large fee. A potential solution for "limbo" tx in general is a kill or fill value. If not included by block x, the tx is void. Client default behavior could be to set kill value for 30 blocks into future for a tx (can be overriden by users). Still the risk is minimal. Tx only go into "limbo" if the user violates spam rules. To do that requires using a custom client and willfully breaking protocol rules. There is no x, and its absence is neither an accident nor an oversight. |
|
|
|
Over time hopefully p2pool will reduce the power of individual pools to impact rule changes, as most miners will just trust the de-facto judgement of the project maintainers in such matters (ie, you). And the biggest pools are all run by friendly, involved operators who aren't driven purely by profit maximization.
The proposed change would make it impossible for users on lightweight clients to do anything with a zero-confirm transaction, even for small amounts. That would make something as trivial as paying for a beer for Bitcoin largely impossible, which seems like a pretty basic litmus test of "does this currency actually work?".
What's more, allowing such double spends would mean that logically it should be extended to already confirmed transactions too. Once merchants all start waiting for 1 block, or 2 blocks, or whatever, large numbers of users would simply start broadcasting double spends after 3 blocks. Once you have enough replacements for transactions 3 blocks back, if all miners use the "profit by default" rule, everyone would start mining on a 3-block back fork automatically in order to claim the higher fees.
The system would become largely useless.
It is one thing to entice miners to prefer one unconfirmed transaction over another unconfirmed transaction. Getting them to revert even one block is an entirely different sort of thing, even for a large reward. P.S. I don't think that the "convert to fee" idea would work anyway. |
|
|
|
GPUs still have that well beat if you buy slightly lower end new GPUs like powercolor 6770s or something like that for around 80$ @ 200Mhash/s that gives you 2.5Mhash/$ minus power though. Undervolted but still OCed they pull around 80W.
You still have to add in the cost of additional hardware. MB, PSU, RAM, CPU, HD or USB, PCIe extenders, frame hardware. Shouldn't be more than about $200 per rig, or $50 to $70 per video card. Even less if you already have some or all of the stuff lying around. |
|
|
|
How do you do the bolded part? And how do you know which is "first"?
The first transaction is the one paying to the recipient (merchant). This is the recipient doing this action. Recipient receives tx 1, paying to him. Recipient receives tx 2, which is a double spend of tx 1 paying back to double spender. Recipient spends tx 1 to all fee. The problem with a double spend is that no one really knows which is the "right" spend. Whichever one ends up in the next block is (by definition) the right one, as far as bitcoin is concerned. If that is the one sent to the unknown person that you are calling "recipient", wouldn't the "recipient" be better off keeping the money? Or are you saying that the miners will be willing to ignore tx2 if they see that (tx1+all_fee) goes into their pocket, unlike tx2, which does not? |
|
|
|
Merged mining is done by putting the child chain in the coinbase field.
Ah, thanks. I can't find much documentation about the coinbase field, but the Wiki mentions "The data in "coinbase" can be anything; it isn't used.", which explains enough for me. Merged chains can't get something for nothing. If there fees are low they why will miners mine them? Ultimately each miner will decide which chains to mine. No current chain with the exception of namecoin has any significant merge mining.
I've been thinking about this, and I haven't figured out yet how this is going to work. In fact, I don't think I understand the mining economics of a future Bitcoin-system that is dominated by transaction fees instead of coin generation. What would prevent a "race to the bottom", where miners ask lower and lower fees, to out-compete competitors? The few miners who happen to have the most efficient computers and the lowest electricity prices will be able to out-compete all others. Once others leave the game, the difficulty decreases, but the ratio between the remaining miners doesn't change. The few successful ones can continue lowering the transaction fee, so that the game remains unprofitable for the other ones. In the end, there is a real danger of a 51% attack. I think that, currently, the only thing that keeps difficulty high is the high value of the generated bitcoins per block. With the generated coin value dropping to zero, I think difficulty will also drop to zero, and the system will fail. Luckily, it will take several decades before this happens, and most in-between lowerings of the amount of generated bitcoins will probably be over-compensated by the increase in value due to increased usage. That's an awful lot of assumptions between now and the system failing in a few decades. |
|
|
|
|
Meh. Who cares? Unless/until the no-transaction blocks start coming back, his botnet, if it was one, is a matter for the cops, not the bitcoin forums.
|
|
|
|
Well I wish I could spend time on little things like linuxcoin. Maybe I'll find the time to make linuxcoin into something more in the future.
Why not just release your live-build configs and such? Shouldn't everything linuxcoin just be in a folder you can make public? I would have donated a long while ago if you hadn't abandoned the project with no source and no ability to move it forward. And it has nothing to do with the abandonment, and everything to do with not being able to move forward. I went to BAMT and have been happy with it, but I still see a future for Linuxcoin. Didn't exist  I didn't use debian's live scripts to create linuxcoin it was all thrown together not really knowing the fully how to put a more official version together so it was all laid out in a folder on an old laptop. Unfortunately I lost the "source". And to tell you the truth I'm not bothered about donations too it was a learning experience and I gained knowledge so I'm happy  I haven't checked my bitcoin wallet for around 8 months. Linuxcoin has soooooo much potential !! I had lots of plans and unfinished work to put in motion I'd love to have the time. Maybe I'll collaborate on another distro. That way I can put as much work in as life allows me without holding up progress. Ha! I don't feel so bad about my ghetto process for building p2pcoin now. I just have a folder and a script to build the squashfs, ISO and torrent. I've been merging packages into that folder by hand. |
|
|
|
|
$1000 invested in GPUs today will get you about 1 BTC per day. If you get free electricity, they should pay for themselves (at current difficulty and exchange rate) around November. FPGA devices will have longer payoff times (assuming difficulty and exchange rate cooperate), but are better if you pay for electricity.
If you love bitcoin and have some spare cash, build a rig and run it, and don't worry about profit.
If you are looking for a longshot investment, build a rig.
If you are looking for a sure profit, I wouldn't bother.
|
|
|
|
Then instead make it in the miner's interest to stay with the first transaction:
When the client software receives a double-spend, display the first transaction as bad and immediately spend its entire amount to fee. It's in the miner's interest to include the first transaction in order to include the all-fee transaction after it.
Double spending is then pointless. You lose your money and still owe the merchant, and it's your fault for spoiling the payment with a double spend.
If the receiver is not online at the time, then he's not a double spending target because he's not even online to act on 0-confirmation transactions.
In the future, this is what any game theory understanding 0-confirmation accepting merchant will do to deter double spend fraud if there are any dishonest miners.
How do you do the bolded part? And how do you know which is "first"? |
|
|
|
http://bitaddress.orgWallet Details tab It runs in the browser (javascript) so you can save a local copy and run it offline for added security. It supports compressed pubkeys too.  Yeah, I've seen that. Of course, my script doesn't have a browser to paste keys into. I'm hoping that I don't need to translate that monstrosity myself, but that might just be my next step. It seems odd that there aren't any command line utilities to package a hex or binary private key into a PEM or DER for openssl to use, and no RPC method to find an address to match an imported key. |
|
|
|
|
No, in that thread they are using openSSL to generate the private and public keys as a random pair. I need to create a public key to match a premade private key.
|
|
|
|
|
So, what is the best way to turn a WIF privkey into a public key / address?
Should I convert the WIF to DER or PEM and let openssl make the public key? Or does anyone have some code that can do it directly?
My target is PHP on Linux, or shell, but I can probably use (or translate) from perl or python.
|
|
|
|
No but just can't be bothered to go through the hassle. I've lost half the stuff and the rest is trivial. It's there if you want to pull it apart and if it was some big ass attempt to steal coins I'd of milked it by now. It's nice to see people still using it and also glad not to hear any stories about loosing bitcoins stored using linuxcoin.
To tell you the truth I'm surprised no one else took it on :/ Anyway I'm leaving the site live at my cost and traffic just on my server alone is in the terabytes.
That was never the main reason. The main reason for open source is to avoid duplication of work. When you gave up on the project had it been open source someone could have taken over where you left off. Without the source there is no "taking over". It is more like "I am surprised nobody started over from scratch to make an alternative". Well they did there are numerous Bitcoin niche distros that started from scratch. Ahh cool I knew of BAMT but haven't heard of anymore ? p2pcoin is largely based on linuxcoin, and it runs a self-contained p2pool node. |
|
|
|
@kjj Nice strawman you put up there. You're imagining a very limited way to use this.
Whitelisted senders will of course not need to send bitcoins/PoW. This solves the mailing list and some other issues.
Until everyone uses this, of course the receiver will not reject all messages that don't have payment. Rather, it will be used to accept messages that would otherwise be mistakenly spamfiltered, which also means that the spam filter can be a bit more aggressive (because those who really want to send a mail to you can do it by sending payment). Going forward it will start deprioritizing paymentless messages, then warn senders that the recipient wants payment for messages, and only after it's a global standard, reject messages without payment.
Also, "Sending email should be free" is stupid, and the amount of payment under consideration here is for all intents and purposes free.
It is a joke. And old, old, old joke. You were supposed to laugh. The problem with spam, as pointed out by others before me, is that spammers are already not paying the cost of sending mail. What makes you think they will start paying for it when you make it more expensive? Why wouldn't they just keep using stolen resources like they do now? |
|
|
|
|
Show Posts
