|
Thanks to those who expressed interest. This job is now taken.
|
|
|
|
I guess the answer delves into the semantics of what is "artificial" versus "natural"...  |
|
|
|
It is impossible, by logical and mathematical design, that the price of the bitcoin could be artificially manipulated by human intervention. The engineer in me reacts to words like "impossible" As a human, I can easily disrupt bitcoins at present with a large enough wad of cash. |
|
|
|
|
A build script for a particular distro would probably be safer, patent-wise. CentOS/RHEL/Fedora do not include the patent-encumbered EC-DSA codes from OpenSSL, and anyone using bitcoin requires that. Therefore, anyone providing builds is providing patent-encumbered software.
IANAL, but apparently, distributing source code or build scripts puts you in a far better position than distributing ready-to-use binary software.
|
|
|
|
CentOS and RHEL are built from the same packages, which are older and more stable. Fedora is built from much newer, packages, often with different software. |
|
|
|
Buyer not having recourse except burning the money will limit the utility, I think.
Perhaps we could work in a way to do arbitration. If both the buyer and seller agree, the money can be diverted to a 3rd party. That person could then arbitrate and either return the money to the buyer, give it to seller or steal it (obviously you'd want to choose a trustworthy arbitrator). That's how online escrow operates today. Buyer and seller agree to let a 3rd party physically hold the money. Buyer and seller both agree to rules that the neutral 3rd party will follow, for transaction resolution / redemption. The neutral third party is the one who disburses funds to one party or the other. This is a pretty decent overview: https://www.escrow.com/solutions/escrow/process.aspSome people might choose to use the bitcoin-specific signed escrow method... but I think the "burn the money" recourse serves as a incentive to avoid bitcoin escrow entirely, rather than an incentive to use bitcoin escrow honestly. |
|
|
|
Due to that recourse, it is unlikely to be used as an escrow mechanism Really? Do you think people won't be able to understand the benefit? (If your response is an argument that there's no benefit at all, I guess that will reinforce the case that people won't be able to understand it.) Existing mechanisms of online escrow (escrow.com, for example) provide more user-friendly methods of recourse. I just don't think "burn the money" is an attractive recourse, nor a natural reaction, for the average human. Ask any salesman to add that to their sales pitch, and gauge their reaction |
|
|
|
|
Buyer not having recourse except burning the money will limit the utility, I think.
|
|
|
|
Updated script URL to gen-check.pl.example, to stop the Web server from attempting to run it |
|
|
|
Sure, printing bitcoins could work I just posted a proposal for bitcoin checks, including source code and a printable PDF example, in the " [RFC] bitcoin electronic check standard" thread: http://bitcointalk.org/index.php?topic=739.0 |
|
|
|
I have developed a sample electronic check for bitcoin. This should work for printed checks, as well as for mobile devices. Maybe we could develop this as a standard for http://bcspec.org/. Note that this scheme requires a payment processor as intermediary, to store the checks until they are paid. Sample check, suitable for emailing, scanning or mobile phone photograph: http://gtf.org/garzik/bitcoin/check.pdfSample output from barcode scanner program zbarimg: $ zbarimg check.pdf
QR-Code:BITCOIN_CHECKv1 u:my_user n:1231-abcd-1231-defa v:100.00 Key: "BITCOIN_CHECKV1": specification identifier "u": user identifier at payment processor. Note: unreliable information (rely on 'n'). "n": unique check id number at payment processor. "v": value. Note: unreliable information (rely on 'n'). Perl source code (requires qrencode program): http://gtf.org/garzik/bitcoin/gen-check.pl.exampleQRcode is a nice, barcode-friendly, photo-friendly method of passing information. It's very flexible. However, the concept of electronic checks themselves have a few notable details: * May work with merchants * May work with mobile phones * Like checks, a simple photograph can enable theft. A normal US check includes bank account info, from which a thief may use to steal your money. With bitcoin checks, the thief may only steal money for the amount of the check. * At the option of the payment processor, a password may be required in order to use the check. * Payment processor may provide option to stop payment on a check. |
|
|
|
Job pay: 1200 BTC, for entire task. Job requirements: - Knowledge of HTML, CSS, JavaScript. - Ability to make an ugly website look good, or at least, less ugly. (read: graphic design experience) - Must have some example of your work available over the Web for inspection (read: a portfolio or references) Job description: I have a website that is full of tabular data. A single page of tabular data, a tiny website. Being a programmer, I can easily spit out numbers. But, wanting to save time and stimulate the bitcoin economy, I'm looking for someone to "pretty up" the website. Give it colors, turn the ugly HTML <table>s into pretty CSS/JS tables. Contact info: If interested, send me a PM on this forum, or email jgarzik@gmail.com with samples of your work. |
|
|
|
I had all four of my cores dedicated previously toward the goal of generating bitcoins, but it's no longer worth the cost to me. I am now only generating using one core but the goal is no longer to generate bitcoins. My current goal is to help maintain the strength of the network and to help the network recover (get to the next block adjustment) when and if a large botnet drops out. Bitcoin was about generating bitcoins, but now it's not. Now it's about competing botnets providing a secure and reliable foundation for an open currency.
Well said. Participation in the network as an honest node helps everyone. |
|
|
|
|
5 BTC sent. Excellent idea for increasing bitcoin exposure.
I agree that the focus should not be on minting new currency, although it is good to mention that participation in "the bitcoin network" includes a small incentive.
|
|
|
|
why bother? Via publish an SDK for it.
I should also point out that you will need the lib files for linking.
The sha256 setup is very likely bitcoin-specific, and you don't need lib files or SDK to simply issue an instruction: asm volatile (".byte 0xf3,0x0f,0xa6,0xd0" /* rep xsha256 */
: \
: "c"((unsigned long)state.count + count), \
"a"((unsigned long)state.count), \
"S"(in), "D"(result));
|
|
|
|
Correct. It is well implemented in the Linux Kernel.
I'll be using it on Gentoo x86 with support built in without a module.
Anyone implementing it in bitcoin will be unlikely to use the kernel support for anything but as a source for code copying... One would almost surely link it into the bitcoin binary. |
|
|
|
|
Selling CDs on eBay is useless, as I found, because their auction-determined worth is basically shipping cost.
So, a used CD store in bitcoin would be interesting, but I think not very productive.
|
|
|
|
|
Show Posts
