Bitcoin Forum
October 27, 2021, 07:57:29 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 »
1  Economy / Currency exchange / Looking to sell Litcoin Cash for BTC, LTC, ETH, or TetherUSD on: February 20, 2018, 05:29:55 PM
Currently at around $9.00 on Yobit - PM me your offers.

I accept BTC, LTC, ETH, and TetherUSD
2  Alternate cryptocurrencies / Altcoin Discussion / Proof of Stake - Majority of Coins Burned on: December 29, 2015, 02:43:57 AM
What happens in a typical proof of stake system if a vast majority of the coins are burned?
3  Alternate cryptocurrencies / Altcoin Discussion / Proof of Stake - Majority of Coins Burned on: December 28, 2015, 11:47:39 PM
Suppose one creates a pure proof of stake coin and then sells 1% of the total supply. He burns 98% and keeps 1% for himself.

Does the network ignore the burned coins or does it keep randomly selecting the burn address as the next block generator 98 times out of 100?
4  Alternate cryptocurrencies / Altcoin Discussion / Gauging Interest - A coin designed around expectation of fiat return on: December 27, 2015, 03:30:38 PM
Sometimes I get kooky ideas, so let me run this by everyone. Also, please don't stop reading at the word "pre-mine".

New coin, rules, expectations:

- 100% premine of an arbitrary amount of coins.

- Issuer sells coins in large lumps on exchanges for very low prices, $.0001 for example.

- After 1 month of selling, all outstanding coins unsold are burned. The result is that the only coins in circulation are those that were purchased for the introductory price.

What happens to the value now?

By buying the coins in the first place, you are pledging to follow certain rules. The rules are these:

- A daily value target is known according to a set function. The value is set to rise from $.0001 to some price per coin over the course of 10 years. The function produces an S curve where the x-axis is time and the y-axis is dollar exchange rate. The upper limit of the curve is set at a target where the market cap of the coin in general is set to $1,000,000,000,000. If, for example, a million coins are sold in the initial offering, then a target price of $1,000,000 would be set at 10 years.

- Participants (buyers) pledge to buy, if possible, any coins below the daily target value and sell any coins above the daily target value.

- After 10 years, the daily target ceases to exist and the coin is free to float as Bitcoin does now.

What is the goal here?

2 goals. The first is to experiment to see if value can become a kind of self fulfilling prophecy, where most participants believe a large reward is within the realm of possibility, therefore they voluntarily behave according to the rules, knowing nearly everyone else is doing the same with the same goals in mind.

The second goal is for the initial participants to make a lot of money.

So... Any community interest in such a project?
5  Bitcoin / Project Development / Nakapay - Looking for developer to modify wallets in exchange for ownership on: April 21, 2015, 03:09:13 PM
Willing to discuss terms. Looking for someone to modify and rebrand existing wallet software to accept Nakapay protocol in exchange for ownership stake in Nakapay.

nakapay.com

michael.nakapay@gmail.com
6  Economy / Digital goods / Nakapay - Service for requesting and making payment via short paycode (SOLD) on: April 21, 2015, 01:37:18 PM
nakapay.com

30 BTC

Includes domain, software, provisional patent.

Installation of software on your server is extra and is to be performed by my developers at your cost (probably a couple hundred dollars or so).

I'll listen to reasonable offers.
7  Economy / Auctions / Nakapay (Software + Server for payment via short paycode and API) on: January 12, 2015, 05:32:38 PM
nakapay.com

Please read the API documentation to learn about the service.

What is included?

nakapay.com domain
control over the namecheap dedicated server on which the site and server is hosted
all existing software related to Nakapay

What is the reserve?

I am including an MD5 hash of the reserve. 840d87b556fe2ba1b7acd68805caa261

When does this auction end?

1-30-15 at 12:00 pm Central Time

I'd like to contact you to learn more about this.

You may PM me here or send an e-mail to michael.nakapay@gmail.com
8  Bitcoin / Development & Technical Discussion / Nakapay - Looking for feedback and discussion on: October 23, 2014, 12:29:08 PM
I've developed a system through which one can request payment and/or pay with Bitcoin using a 6 character paycode. I call it Nakapay.

I'd like to get eyes on it, but not sure if I'm doing it correctly. The prior announcement is below. Is this the kind of thing that would merit a BIP?

"So I've been working on something for some time now. Like many here, I've long felt that one of the primary things holding Bitcoin back from mainstream adoption is that the actual payment procedures that we use currently are too cumbersome, too alien, and too difficult for a casual first time user to wrap their minds around.

Bitcoin as a payment system is a complex notion as it is; it doesn't need to also be complex to use.

Various efforts attempt to solve this problem, but users are still waiting for a user interface moment.

I present to you Nakapay and details can be found at nakapay.com.

Nakapay is a protocol that can be used by a Bitcoin wallet to request and send Bitcoin without involving QR codes, e-mail, hyperlinks, usernames, passwords, Bluetooth, or a specific location. It is also wallet agnostic, meaning any wallet developer who wishes to let their users use Nakapay may do so.

How will it look in a wallet?

Using Nakapay means one takes on the role of either a merchant or customer. A merchant can simply be seen as an entity or wallet that is requesting Bitcoin; a customer is the party that sends Bitcoin.

A merchant simply uses a Nakapay compatible wallet to generate an invoice, which can be done by merely entering an amount of Bitcoin the merchant wishes to receive and a time limit on the invoice. The wallet will present a paycode to the merchant, consisting of 6 characters with numbers 0-9 and letters A-F. They look like this, 398F22, AA90CA, or 89DAA1. The merchant communicates the paycode generated to the customer in any manner the merchant desires.

The customer, using a wallet that has integrated Nakapay, enters the paycode into his wallet. His wallet then populates the amount and address the merchant is requesting. It also reveals how much time the customer has to pay the invoice before the merchant may consider it to be invalid. The customer verifies that everything looks correct and pays.

What kind of safety processes are in place?

When pitching this concept to various wallet developers, I was met with a concern that such a system, while convenient, is unsafe because the paycode server can modify invoices. Customers entering a paycode thinking they are paying .1 BTC to their friend might inadvertently being paying 10 BTC to either Nakapay or some attacker. This is obviously a legitimate concern.

There are 3 layers of protection. The first layer is within the rules of the protocol itself. The way that a paycode is generated has to do with the contents of the invoice itself. Paycodes are truncated SHA-256 hashes, where the paycode consists of the first 6 characters of the hash. The data being hashed is the content of the invoice: the amount, address, name of merchant (not verified or needed), timestamp of invoice, and timestamp and expiration time. A server attempting to falsify invoices will be required to create and invoice that generates a paycode identical to the paycode entered by the customer.

Second, the invoice, including the paycode, is signed by the merchants wallet using the key of the receiving address. Any customer (or merchant, or anyone just entering random paycodes for that matter) will receive the signed invoice and can verify that the person who created the invoice has control of the address within. One cannot modify an invoice without invalidating the signature. Therefore, a merchant wallet that generates an invoice should also request the generated invoice from the paycode server and only treat the paycode as valid and unmodified if the signature returned is identical to the signature sent.

Third, Nakapay does not intend to run a exclusive paycode server. If a number of entities operate separate servers, wallets generating invoices may submit invoices to multiple paycode servers. Customers may submit identical paycodes to multiple paycode servers as well, and ideally, all servers should return identical invoice signatures. If, for example, four of five servers return identical signatures (invoice must be identical), and one returns a different signature, it may be inferred that either the invoice has been tampered with, the server is holding an old invoice, or a user submitted an invoice to that server alone before the subsequent user sent his invoice to the five servers. Over time, which paycode servers are reliable, colluding, fraudulent, etc... will be sussed out.

At the present time, if you'd like to run your own paycode server, you may. If you'd like to purchase a copy of my software, please contact me and we can try to work out a deal.

How does Nakapay intend to make money?

Initially, the service will be run for free. At some point in the future, if the service is seen as viable, convenient, and trustworthy, the plan is to charge users for revealing the merchant's receiving address. The fee that I have in mind is somewhere in the neighborhood of .1% to .25%, which means that if Nakapay receives an invoice for 1 BTC to merchant's address, it reveals everything to anyone using the paycode, save for the merchant's address until a fee of .0025 BTC is paid to a fee address controlled by Nakapay. After the fee is paid, the server reveals the entire invoice. No confirmations are necessary for the fee payment.

Other paycode servers are free to operate under any payment scheme they wish.

Where is your API documentation?

https://mega.co.nz/#!QBImCbrC!xly7IS49gSuhvDzi5LtobVZXEiSsC7KcHoH8B-IqKjM

I'd like to use Nakapay, but there are no wallets that have integrated it. How can I help?

If you are a Bitcoin user, encourage the developers of the wallets, merchants, and Bitcoin services you use to incorporate Nakapay into their systems.

If you are a Bitcoin developer, especially a wallet or payment processor developer, work to incorporate Nakapay into your wallet or invoice services.
One thing to keep in mind is that just as Bitcoin augments traditional payment systems, I envision Nakapay as augmenting the traditional methods of populating a Bitcoin wallet.

I'd like to talk more about this with you. How can I contact you?

michael.nakapay@gmail.com"
9  Economy / Service Announcements / Announcement - Nakapay - Using short paycodes to request payment or pay on: October 21, 2014, 09:17:25 PM
So I've been working on something for some time now. Like many here, I've long felt that one of the primary things holding Bitcoin back from mainstream adoption is that the actual payment procedures that we use currently are too cumbersome, too alien, and too difficult for a casual first time user to wrap their minds around.

Bitcoin as a payment system is a complex notion as it is; it doesn't need to also be complex to use.

Various efforts attempt to solve this problem, but users are still waiting for a user interface moment.

I present to you Nakapay. nakapay.com

Nakapay is a protocol that can be used by a Bitcoin wallet to request and send Bitcoin without involving QR codes, e-mail, hyperlinks, usernames, passwords, Bluetooth, or a specific location. It is also wallet agnostic, meaning any wallet developer who wishes to let their users use Nakapay may do so.

How will it look in a wallet?

Using Nakapay means one takes on the role of either a merchant or customer. A merchant can simply be seen as an entity or wallet that is requesting Bitcoin; a customer is the party that sends Bitcoin.

A merchant simply uses a Nakapay compatible wallet to generate an invoice, which can be done by merely entering an amount of Bitcoin the merchant wishes to receive and a time limit on the invoice. The wallet will present a paycode to the merchant, consisting of 6 characters with numbers 0-9 and letters A-F. They look like this, 398F22, AA90CA, or 89DAA1. The merchant communicates the paycode generated to the customer in any manner the merchant desires.

The customer, using a wallet that has integrated Nakapay, enters the paycode into his wallet. His wallet then populates the amount and address the merchant is requesting. It also reveals how much time the customer has to pay the invoice before the merchant may consider it to be invalid. The customer verifies that everything looks correct and pays.

What kind of safety processes are in place?

When pitching this concept to various wallet developers, I was met with a concern that such a system, while convenient, is unsafe because the paycode server can modify invoices. Customers entering a paycode thinking they are paying .1 BTC to their friend might inadvertently being paying 10 BTC to either Nakapay or some attacker. This is obviously a legitimate concern.

There are 3 layers of protection. The first layer is within the rules of the protocol itself. The way that a paycode is generated has to do with the contents of the invoice itself. Paycodes are truncated SHA-256 hashes, where the paycode consists of the first 6 characters of the hash. The data being hashed is the content of the invoice: the amount, address, name of merchant (not verified or needed), timestamp of invoice, and timestamp and expiration time. A server attempting to falsify invoices will be required to create and invoice that generates a paycode identical to the paycode entered by the customer.

Second, the invoice, including the paycode, is signed by the merchants wallet using the key of the receiving address. Any customer (or merchant, or anyone just entering random paycodes for that matter) will receive the signed invoice and can verify that the person who created the invoice has control of the address within. One cannot modify an invoice without invalidating the signature. Therefore, a merchant wallet that generates an invoice should also request the generated invoice from the paycode server and only treat the paycode as valid and unmodified if the signature returned is identical to the signature sent.

Third, Nakapay does not intend to run a exclusive paycode server. If a number of entities operate separate servers, wallets generating invoices may submit invoices to multiple paycode servers. Customers may submit identical paycodes to multiple paycode servers as well, and ideally, all servers should return identical invoice signatures. If, for example, four of five servers return identical signatures (invoice must be identical), and one returns a different signature, it may be inferred that either the invoice has been tampered with, the server is holding an old invoice, or a user submitted an invoice to that server alone before the subsequent user sent his invoice to the five servers.

Over time, which paycode servers are reliable, colluding, fraudulent, etc... will be sussed out.
At the present time, if you'd like to run your own paycode server, you may. If you'd like to purchase a copy of my software, please contact me and we can try to work out a deal.

How does Nakapay intend to make money?

Initially, the service will be run for free. At some point in the future, if the service is seen as viable, convenient, and trustworthy, the plan is to charge users for revealing the merchant's receiving address. The fee that I have in mind is somewhere in the neighborhood of .1% to .25%, which means that if Nakapay receives an invoice for 1 BTC to merchant's address, it reveals everything to anyone using the paycode, save for the merchant's address until a fee of .0025 BTC is paid to a fee address controlled by Nakapay. After the fee is paid, the server reveals the entire invoice. No confirmations are necessary for the fee payment.

Other paycode servers are free to operate under any payment scheme they wish.

Where is your API documentation?

https://mega.co.nz/#!QBImCbrC!xly7IS49gSuhvDzi5LtobVZXEiSsC7KcHoH8B-IqKjM

I'd like to use Nakapay, but there are no wallets that have integrated it. How can I help?

If you are a Bitcoin user, encourage the developers of the wallets, merchants, and Bitcoin services you use to incorporate Nakapay into their systems.

If you are a Bitcoin developer, especially a wallet or payment processor developer, work to incorporate Nakapay into your wallet or invoice services.

One thing to keep in mind is that just as Bitcoin augments traditional payment systems, I envision Nakapay as augmenting the traditional methods of populating a Bitcoin wallet.

I'd like to talk more about this with you. How can I contact you?

michael.nakapay@gmail.com
10  Bitcoin / Project Development / Looking for programmer on: July 15, 2014, 08:37:01 PM
Looking for programmer to enter NDA to discuss idea for project involving server side work. Project will likely take approximately 1 month to complete and terms *are very negotiable.

PM me with portfolio.

Must accept Bitcoin as payment.
11  Economy / Goods / Home Theater Speakers - Definitive Technology - San Antonio, TX - SOLD on: March 24, 2014, 09:34:29 PM
http://sanantonio.craigslist.org/ele/4390018924.html

Full Definitive Technology home theater speaker set available. This one is extra nice and minty...

Main Towers - BP6B (aka BP-6) - New condition in boxes - http://www.definitivetech.com/products/bp6b
Center Channel - C/L/R 2500 - Good to Great condition - http://www.definitivetech.com/products/c-l-r-2500
Surround Channels - BP2X - Great Condition - http://www.definitivetech.com/products/bp2x

All items flawlessly functioning and perfectly matched. Center channel features a powered subwoofer which can be used as a subwoofer, or as a compliment to your center channel, for extra dialogue power.

For an extra $300 a wonderfully matched and musical Velodyne DPS-12 subwoofer can be added, along with delivery to San Antonio and surrounding areas.

Will accept Bitcoin.
12  Economy / Goods / 2006 Range Rover Supercharged - San Antonio, TX on: November 20, 2013, 06:57:53 PM
http://sanantonio.craigslist.org/cto/4203745151.html

May be willing to work out interesting Bitcoin trade.  PM me your offers...
13  Other / Off-topic / Anonymous Mail Service on: October 16, 2013, 03:11:18 PM
Let's call the venture AMS.  Suppose S wishes to send a package to R.  S could use the standard mail system or one of the large package carriers, like FedEx, but such methods are not anonymous, costly, and slow.  They are costly and slow because it is assumed that the carrier will be delivering to a home or business, not to a hub.  They are not anonymous because names are attached to S and R.  The names could be false, but using false names throws a wrench into the normal operations of these businesses.

The reason these services are not anonymous, cheap, and fast is because they operate using an old model, requiring enormous manpower and infrastructure.  If we were building the system from the ground up today, using the technology of today as the starting point, it would look radically different.

For many people, going somewhere in their city to pick up or drop off a package poses no challenge.  With this, we eliminate the last-mile problem of package delivery, but if customers require home/business pick up or drop off, private couriers would be able to handle that load.  So the real idea is simply this, a nameless system for delivering packages between cities.  Let's suppose we did this in only Texas, where there are several major cities.  The model can cover any geographic area, though.  Simply put, one need only have deliveries between cities several times per day before you end up with a system radically faster than the post office.

S wants to send a package to R.  S doesn't want to know who R is and R doesn't want to know who S is.  Neither party wishes to know where the other party is.  S lives in San Antonio, but R doesn't know this.  R lives in Waco, but S doesn't know this.  Neither party wishes to know.  Both have accounts with AMS and they create an encrypted shipping label QR code on the AMS website.  The QR code contains limited information.  Translated it will show only R's bitcoin address, postage amount required to deliver, AMS's bitcoin address to be funded, and the name of the AMS office where the package is destined.  The only one who can decrypt the label is AMS.  When they do, it reads..

Receiver = 16DJXXZBX7JZQWwnYoqt6Xe9VjUDRRvHpK
Postage = .025 BTC to 1AvttuYUd6Xtv3Vt8B96UbT9xDns7Yzzt1
Waco

The only information revealed to both parties in this process is the postage amount and bitcoin address to which it must be sent.  One or the other or both may fund it.  When funded, S merely drives to the package to the San Antonio office and hands it off.  Behind the scenes, the QR code is read and decrypted.  AMS now may verify with the blockchain that the postage is paid and the end point is Waco.  There is a major city between San Antonio and Waco, Austin.  AMS San Antonio has a list of all other AMS hubs and it knows that all packages going to Waco must first go through Austin.  From the AMS office in San Antonio, there are only perhaps 5 places their packages may go.  From those places, there are also only limited numbers of immediate destinations.  Is this network reminding you of anything?  Routing would be as simple as placing the package on the correct conveyor belt and letting it reach the end where it is stacked onto a cart.

Eventually, the package gets to the AMS Waco office and a message is sent to R.  "Your package is ready to pick up.  Your verification code is (the transaction ID for the first deposit into the postage address)."  In order for R to pick up the package, he must prove that he is the owner of 16DJXXZBX7JZQWwnYoqt6Xe9VjUDRRvHpK.  He signs the transaction ID with the private key to 16DJXXZBX7JZQWwnYoqt6Xe9VjUDRRvHpK and after AMS verifies the signature, now AMS knows that this person, whoever he or she is, may receive the package.  AMS hands him his package.

The system works just as well if you do wish to know who the parties are as none of the steps change.  It works exactly the same way.  But now let's go a step further.  S doesn't want even AMS to know that that he is in San Antonio.  Now S may route the package through any number of hubs by simply putting packages in packages and making the receiver on the outermost package AMS itself.  AMS has an internal policy whereby S may give to AMS a package with a label that only AMS my verify.  R is unaware that this is happening.  S puts the package described above into another package with its own shipping label.  This shipping label is a combination of S and AMS's information and S decides to route it through Dallas.  Now the package makes its way to Dallas in the manner described above, only now, it gets opened by AMS Dallas itself, where inside they find yet another package, with its own shipping label.  They throw it on the pile and scan it along with everyone else's packages that are coming from Dallas.  When it arrives in Waco, AMS only knows that it last came from Dallas.  S may pay for as much anonymity as he desires, routing it through multiple hubs before eventually the last package is left for R.

Imagine each truck going from city to city holds about 500 packages and each hop is calculated to be $2 flat rate up to 3 pounds or something.  Going from San Antonio to Waco would have 2 hops so the postage would be $4.  Delivery drivers are essentially independent contractors, going to the AMS office and seeing which run needs to be made.  Drivers get a negotiated percentage of the hop, so a full hop with 500 packages at $2 would be a percentage of $1,000.  And they'd need to come home as well, so they'd get their hop on the way back as well, because there will be packages going San Antonio.  Imagine the speed this would foster, with drivers doing everything in their power to make their runs for the day, bidding down the cost so that it is profitable for them ... but cheap for AMS.  At 25%, the driver could make $500 going from San Antonio to Austin and back again.  The driver might be loading and unloading, but with small boxes, this is trivial.  With enough hops, say 10 hops from LA to NY, a plane covering them all could become profitable.  All S and R know is that they're paying for 10 hops.  Little do they know they will all be covered in one fell swoop with a same day plane.

A pilot would cover 10 hops, so $20 per package and he might have at his disposal enough room for 10,000 packages or more.  Now all these S's going from LA to to R's in NY wind up with possible same day delivery because the pilot sees a profit at $50,000 per flight to NY... and of course another $50,000 on the way back, at 25% of the hop.

Something worth looking into?  I suspect the vast majority of this operation could be franchised out, with entrepreneurs opening up their own hubs, drivers running their own rigs, and private couriers covering the last mile for end S's and R's.
14  Alternate cryptocurrencies / Altcoin Discussion / Wanted - Programmer for 2 new alt-coins (BOUNTY - 5oz of silver OR BTC) on: April 19, 2013, 09:21:53 PM
Is there anyone out there that would be willing to create a couple alt coins for me?  GDC (Goldcoin) and SRC (Silvercoin).

I have a couple specifications.

1 - All 100 billion coins are premined in first block and go into vault wallet, accessible only by me, meaning I mine the first block.
2 - 50% of all future transaction fees go to me.
3 - 50% of all future transaction fees go to miners.
4 - Coin can be merge mined with Bitcoin.

This is the plan.  Create one coin backed by gold and another backed by silver.

Gradually, people will begin to trust me with their gold and silver, which will be kept in safety deposit boxes in various banks and available on request from people who are able to send me units of these alt coins.

1 coin will equal 1oz of metal.  If someone sends me 1GDC, they will be sent 1oz of gold bullion from my safety deposit box.  If someone sends me 1oz of gold bullion, I will send 1GDC to their GDC address.  GDC's are always redeemable by me in metal as there is a 100% reserve, but shipping costs will apply.

Various other details will be worked out in future posts.

The transaction fees going to my personal address may be sent to the vault wallet so that I may redeem the metal to sell and pay for safety deposit box rent, personal expenses, etc...

As a reward for this task, I'm offering to send 2SRC's to the programmer, which he may keep or redeem with me for 1oz coins.

This is purely an experiment to see what, if any, demand for this sort of thing is out there.

*offer increased to 3SRC's
*offer increased to 4SRC's or a negotiated amount of BTC.
*offer increased to 5SRC's or a negotiated amount of BTC.
15  Economy / Service Discussion / Mail a check for USD for BTC - Testing the waters on: October 25, 2012, 04:02:47 PM
I am thinking about opening up a web store that will essentially sell checks via mail for BTC.  Users would need to be in the United States and checks would go out M-F.  As such, users would be getting their USD much sooner than if they were to sell BTC on an exchange, then move the money to Dwolla, then move the money from Dwolla to a bank account... etc...

It will start very small - maybe only 10BTC for sale at a time, but I hope it will grow after that.  Fees would be in the neighborhood of 2%, plus a $1 shipping charge.

I am looking to use existing e-commerce software, but existing solutions seem to be few and far between.

So here is what I'm looking for...

A simple site that displays the amount of USD available for purchase.  This would go down as people make purchases, like a store's stock of items.

A field where the user can enter the amount of USD's they want to buy.

A purchase button.

The user clicks the purchase button, enters in their info (name, mailing address, etc...), and they are shown a BTC address to fund, with a timer that will tick down.

Once they fund the BTC address, a confirmation e-mail is sent to both the purchaser and me.

I will be using MtGox to replenish my checking account as it runs low, so using the MtGox merchant API would seem to be a fit here... but I don't know how to use such things.

So... what do you think about this?  Would someone be willing to code such a thing if there isn't an out of the box solution already out there?  If so... what would you charge?
16  Economy / Computer hardware / WTS - Butterfly Labs Jalepeno Pre Orders (1 unit sold + update) on: September 29, 2012, 05:51:11 PM
Order #6341* for 1 Jalepeno - 15BTC   send to 1EspdyKARvSqKpW8kEC6vBPhRJFRmwSt1s  (SOLD)

Order #6637 for 2 Jalepenos - 29BTC  send to 1FZgwJXeqF7EsSs3vrBikWoSZxj14e29Sh

Order #6714 for 2 Jalepenos - 29BTC  send to 1JJYvRrDntsozMjuUXybH5UmGzbMLCk8Rw

After payment, I will have Butterfly Labs replace my order information with your own, so instead of sending to me, they will send to you.

I paid for US shipping, so if you're not in the US, my order may not cover your shipping.

Or make me an offer in PM.

* edit

It looks like BFL will not replace shipping info.  Make an offer for me to ship unopened whatever they send me, whenever they send it.  They have stated that they can confirm orders and they'll be able to confirm that I have these orders.

* edit

was 6314, transposed 4 and 1.

* edit

10-3-12 - I have put in an email inquiring about an upgrade 4 of my orders to the Little SC.  BFL_Jody on the Butterfly Labs Portal has stated that if you have orders for 4 or more Jalepenos, for some additional BTC (I'm guessing about $50 worth), the orders can be upgraded to a Little Single while keeping your place in line.

Offer - Buy the remaining 2 orders of 4 Jalepenos (#6637 and #6714) for 55 BTC and I will continue pursuing the upgrade for you.  I will even cover the cost of completing the upgrade up to 5 BTC.

* edit

10-5-12 - Having not received any offers on the remaining 4 Jalapenos, I have upgraded them to a Little Single with Butterfly Labs.  Because the opportunity I was hoping to capitalize on has passed, I will simply keep the Little Single when it arrives and mine with it myself.

Edd will get the remaining Jalapeno when it arrives.

I'm now locking this thread.
17  Economy / Service Discussion / So when are we going to look into really finding Pirate? on: September 11, 2012, 12:51:36 AM
Is this so difficult?
18  Economy / Securities / Are there any listed securities for this type of thing...? on: August 23, 2012, 10:26:54 PM
What I'm envisioning is a company listed on GLBSE that does the following...

Operator sells 49% of company in IPO.

Funds are used to purchase mining equipment, whatever is available at the price equal to what the shares sold for (or to wait in line with BFL).

All mining goes into wallet that is publicly visible (address is known) and is considered an asset of the company, along with the hardware.  The wallet is offline only and backed up appropriately.

At such time when a sale of 50% of the wallet would yield enough $ or BTC to purchase more equipment (another ASIC, for example), 50% of the wallet is spent on more hardware.

This is designed to last in perpetuity, however, should the majority owner decide to close up shop, he sells equipment for BTC or $ converted to BTC (into publicly visible wallet) and divides the wallet among shareholders.

Anything out there like this?
19  Economy / Service Discussion / Quick Question - What if Pirate didn't say he would pay in a week or two? on: August 22, 2012, 06:54:05 PM
What if he stated from the outset that he'd be paying in 1-2 months?

After 6 weeks, would the pro-Pirate people be saying, "Well... he did say it could take 2 months..."?

What if he stated that it would take 6 months?

After 5 and a half months, would they be calming the naysayers?  "He did say it might take 6 months."

Is there any conceivable time frame he could have given that would simply be too long for anyone to believe?
20  Economy / Currency exchange / [WTB] Bitcoins with Dwolla (CLOSED) on: August 21, 2012, 05:24:36 PM
Want to buy 6 BTC.  Any offers?
Pages: [1] 2 3 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!