Thanks for the detailed comments. For a) I can see how that is true when using anyone-can-spend outputs (OP_TRUE), but how could the miner change the destination if it worked like I described?
1. User negotiates with n number of nlocktime-relay nodes and receives their fee address
2. User creates n number of tx's, each with a standard fee and an output to the nlocktime-relay's address

(I'm just realizing that I don't know at a low level how transactions fees are added to transactions, the tx fee wiki didn't have much. Are they just anyone-can-spend outputs?)

Using this method the outputs are fully defined and signed in the tx (except for the normal fee), so the miners couldn't modify the output to the nlocktime-relay anymore than they can modify outputs of blocks today (I think).

There are obvious downsides like the negotiation and manually broadcasting the nlocktime'd transaction to each relay, but still possible.

however you are one step ahead of me with (b) and I don't have a great response.
With a theoretical hardfork this nlocktime'd fee being paid could be unlocked a certain number of blocks before the rest of the transaction is unlocked and broadcast. Maybe it could be a somewhat complex system where it costs the nlocktime'd fee slowly becomes available so these nlocktime relays can slowly drain this fee. But if you're sending this to 10,000 nlocktime relays they all leach off a fee... bleh

The better option is to come up with a new nlocktime since we're basically trying to solve usecase #2 from here. Where (with a hardfork and a new lock time construct) we could insert the locked tx's into blocks, but not let them be spendable until the lock expires. Solves a lot of the broadcasting issues, and seems like the more needed usecase for locked txs.

netstat -tulpan
and
tcpdump -n -i eth0 port not 22

both look ok for me.

Of course they could've patched both of those programs but that's a lot of extra work. Feel free to throw a hub inline and sniff from another computer if you're worried about that.

And you have no reason to trust me so check those yourself.

It seems like a simple incentive problem. What if when a user creating a tx that is locked in the future, could offer a reward for either a node storing the tx until the lock expires (then it will broadcast it). Instead of only having a fee that goes to the miner of the block, an additional fee could go to the node that stores and eventually broadcasts the transaction.

I guess the naive approach would be for someone creating this future tx to create multiple copies of the tx, each with a different destination "rebroadcast fee" address. So certain nodes could advertise "I rebroadcast transactions up to n blocks from now with a fee of n*(fee)". Then the user creating the tx would create a new copy of the tx for each "rebroadcast node" it sends the tx to, with that specific rebroadcast node's fee address.

Maybe this has been discussed somewhere else, but just a thought.

Bumping this because I still don't see a good way to verify windows binaries after a brief search on the latest client.

The release announcement for the latest 0.8.4 does not include any signatures like some old ones did

What is much worse is source forge seems to only allow http downloads. Manually changing it to https seems to redirect me to http on the mirror and sourceforge webpages I tried.

So I guess my ask is to include signed sha256 sums in all release announcements and on the bitcoin.org websites download page since many people wont go and find the announcements.

And a tutorial link similar to what these guys have put together would also be helpful I think for newbies

Can cgminer support scrypt (on gpus) and blf asic's on the same computer? Would you have to run two instances? Does the --scrypt and --bfl options automatically designate which instance should mine off which hardware?

last bump, 1 BTC for all 64 credits

bump

price drop to 0.025 btc per credit. So 1.6 btc takes all 64.

Screenshot, and again open to escrow.

http://i.imgur.com/xkP6bO5.jpg

Price drop to 0.03 per credit which works out to $2.70 usd with bitcoin worth $90

.03 * 64 = 1.92 BTC for all 64 credits

I have 3 batches of butterfly labs chip credits for 16, 16, and 32 chips. Each credit is worth $25 discount per chip.

More info here

https://forums.butterflylabs.com/announcements/3272-customer-appreciation-chip-credit-program.html

Open to escrow.

Asking 2.5 BTC (or litecoin equivalent) total or best offer within a few days. (works out to $3.87 USD per credit @ $99/BTC)

Makes sense, thanks for the detailed explanation

Does each worker on a pool get the same block header though? Because, assuming this works, you could do it on the same pool with multiple workers, it would just be much easier to detect.

Hopefully someone can explain why this wouldn't work, I can't be the first person to think of this.

Say I have an account on two different pools
worker: scrubadub.1 on pool A and
worker: scrubadub.2 on pool B

Let's say I can set the var diff manually on both so I set...
scrubadub.1 to vardiff 64 and
scrubadub.2 to vardiff 32

Now I start mining.

If I get a share above 64 I submit it to worker scrubadub.1. That pool accepts it and also credits me for the expected amount of shares under 64 that I would've also found (and not submitted) depending on the rate of shares that I submit above 64. If we stop here I would get credited for roughly 100% of the shares I find (with a little variance)

But, while I'm still mining if I find a share between 32 and 63 instead of just dropping it I instead submit it to scrubadub.2. That pool accepts it and credits me for that share and the expected number of shares I would've also solved below 32 given the rate that I submit above 32.

At the end of the day I ended up with a much larger credit of shares than I actually solved. Pool A can't see any difference in the way I submit shares, Pool B could if I'm so clear cut about it, but you could get more random in what you submit.

So I guess my question is can I locally generate my own work or am I forced to solve the work from the pools (which would prevent this). Looking at my cgminer output for locally generated work (LW:) it seems quite high, but I'm not sure how many "locally generated work" are required before a share is found.

Thoughts?

I like your usecase, I agree it has the potential to stop a lot of hacking attempts, though it somewhat goes against the idea that once bitcoins are sent they are gone.
Would they have to go in the block chain? If the pending transaction was somehow prevented from being confirmed for say 24 hours or so, the owner would still see there is a pending transaction and could send a new version of a transaction to change the destination (it would have to be in the memory pool for that length of time). Though like you point out, only if there is a way to always force transactions from not entering the block chain for a set period of time, and if there is always a way to +1 the version number, otherwise an attacker would just use the highest version.

It might be cool to allow users to set that the bulk of their coins can not be spent without X days of wait time. And maybe another percent of their coins couldn't be confirmed without Y hours of wait time (all determined by the owner). Then if the user wanted to make a large purchase they would just choose to not renew their X days of wait time (or shorten it) on the bulk of their coins.

This would also prevent the transaction from sitting in the memory pool for a length of time. Say a user locks some amount of their coins for 4 days, they could renew this 4 day lock every 24 hours. So if an attacker knew the private keys they would constantly be unable to post a transaction until they prevented the user from locking their coins. However this could obviously go the other way, an attacker could constantly lock your coins from your own use, basically destroying those coins.

I'm not sure how you might achieve this within today's constraints but it is interesting.

Thanks for the input, I have a few questions. Hopefully you can clarify a few things for me.


I'm not sure I understand how this would work, but could the sender still just release a new version of the payment?
Sender addy A ---> Receiver addy B (maybe with a locktime, or unsigned output)
Both the sender and receiver have to sign it before it is added to the blockchain. So the sender can just refuse to sign the transaction until they want the coins to be spendable, but this requires the sender to be alive/remember his keys/sign the transaction at the time he wants it to be spendable.
Plus couldn't he just refuse to sign the transaction and keep the coins?

In my example #2 I was going for a way that the sender "fires and forgets" a transaction with coins, and no matter what the receiver will have those coins available to him, after some amount of time.


We wouldn't have to take over the nLockTime parameter and change its meaning from today. Could we just come up with a new parameter scrubadubLockTime (or whatever) that is treated differently and would work for case #2. Would this prevent a hard fork?

Again I would suggest that the transaction is added to a block immediately, but the receiver can not spend those coins until the scrubadubLockTime expires, so the parent transaction would have to be checked when the receiver tries to spend them. And there is nothing the sender can do to get the coins back since they are in the blockchain.


Who controls the address that Tx1 is being sent to? An escrow service of some kind or the sender, or is it just some dead address that no one is supposed to have access to (how can you know that someone doesnt control the private keys)?
Ok so after Tx1 is sent, both parties sign the transaction and it goes into a block. Like you say the sender (and receiver?) dont have control over the coins at this point.
Who creates this Tx2? wouldn't they have to know the private keys of the output from Tx1? So whoever can create a Tx2 with nlocktime without it being final could update that transaction to remove those restrictions right?

I read through the contracts wiki again, I think you were describing the escrow example, but I'm not sure it fulfills my #2 transaction example. https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
Could you be a little more verbose in your example for me?

Thanks

Shamelessly bumping for comments on bitcoin supporting three different types of transactions based on locktime (discussed above).

Thoughts?

I think the better idea would be to implement bitcoin contracts and take advantage of them

https://en.bitcoin.it/wiki/Contracts#Example_3:_Assurance_contracts

It seems like there are three ways someone may want to use transactions/locktime

1. Send a transaction with locktime and revoke or change it before the lock time
2. Send a transaction with locktime and be unable to change it, yet the party receiving the transaction can still not spend it until locktime
3. Send a transaction and shortcut the locktime (basically a normal transaction, described below with uint_max)

So reading this thread I understand transactions aren't in blocks until they are final / locktime expires (unless unit_max), but I'm thinking more theoretically for a second on how it should/could work.

So usecase #1 seems covered today, I'm told you can resend transactions without the lock time or with a new version and other miners will confirm this (correct me if I'm wrong)
And usecase #3 is basically a normal transaction without locktime.

The interesting usecase is #2 I think. Here are a few problems I see...

Right now nodes probably wont relay transactions with a future locktime of n days out, forcing the party creating the transaction to resend the transaction closer to the locktime or give the transaction to the receiving party to retransmit. Possible solution to this problem is include the transaction in the blockchain, it would be not be able to be changed but that is the purposes of usecase #2.

Because the transaction is not confirmed until the future locktime, the sending party can create another transaction and mine a block their-selves (or ask someone else to) and reverse a transaction with a future locktime. The only way around this I see is to add future transactions to the blockchain.

So if you did add the transaction to the blockchain then your problem is how do you prevent the receiving party of the transaction from spending the coins before locktime. Though this seems like a easier problem than trying to solve the above two problems. Is it not possible to check the parent transaction of a newly created transaction to make sure it is valid at the time of the new transaction?

Again I (think I) realize how it works today, but I dont think this usecase #2 is covered today (please correct me if i'm wrong). Assuming #2 isn't covered today, would adding future transactions to the blockchain, and verifying the parent transaction's locktime be possible? Or does that break all kinds of other things I'm not thinking about.

Thanks

The new site is at https://lc.ozcoin.net because turned on port 80 mining I think

newlc.ozco.in seems down. Did you take down the old (closed) pool and move the new pool to https://lc.ozcoin.net from now on? Will I have to transition my workers from newlc.ozco.in to something else?

Edit: I used to be able to hit 80 via www but now since that is used for mining I'll move to https://lc.ozcoin.net like i probably should've.

It is a little confusing because the first post on this thread contradicts what is on the site.

r3R8VKSaj7Emp3sMwsVAECb8moeEuM5Qt8