Maybe not a good place for this, but I want assign some coins to the chain which can only be spent if N out of M private keys sign the transaction. What's the best way to do this? Thanks  Right now, I think you'd need to write the script by hand and probably mine it yourself too. |
|
|
|
That's a stupid idea.
If this goes through, I'll buy up tainted coins for cheap. Then I'll mine dummy txs to myself, using the tainted coins for huge txs fees. Since I won't broadcast them, sooner or later ... PROFIT That should only take you 6 or 7 months mining by yourself, provided the difficulty stays the same (and it won't). Again, spotting the outsize txn fee won't be hard and marking the entire block as tainted will be easy to do. Someone that stole thousands of coins could easily include overly generous fees in lots of blocks, not just their own. Spotting those fees won't be hard, but most of them will be decoys. Real life money laundering also has poor returns, so don't imagine that someone would be unwilling to lose 90% to have a clean 10%. |
|
|
|
Still, you could have 10 miners, which all mine with 10MH/s and requesting different difficulty work. Like 600, 700, 1000, 10000 etc. These 10 miners would together have 100MH/s hashing power.
Besides those 10, you have one big miner (or farm) which hashes with big hashing power. When a block is found, the block is forwarded to one of the 10 miners, depending on which target was solved. If the solved block has a 1150 difficulty, it is forwarded to the "I requested 1000 difficulty"-miner, who receives the payout.
So, I believe the stated solution works only for people who use one miner only.
Ente
The target difficulty is apparently encoded in the coinbase to stop people from doing that. |
|
|
|
This was just discussed at length. Go back a page or two, or skip right to the conclusion. |
|
|
|
Am I correct in thinking that p2pool now provides variable size shares? Will shares found that are higher than the current (network) difficulty automatically scale, or does it need to be set in advance?
Well p2pool has always supported variable difficulty shares. This simple lets you set a higher than minimum diff. You would need to set it ahead of time. If you don't cheating is trivially easy. Look I just found a diff 200,000 shares woot. I get credit for 40,000 shares! Yeah, that's what I was getting at. I just didn't want to spell it all out in public until I heard from forrestv that it was taken care of. Ah I see. Oops. Well looking over the code I the share difficulty is part of the block header. Thus diff is defined before hashing and once you find a share it is only good for that difficulty as you submit share data long w/ hash to the share chain to allow other nodes to verify. The bitcoin network target is in the block header. This is not the same as the p2pool target. |
|
|
|
|
Finally, TC being used for good instead of evil!
|
|
|
|
lower receiver assembly placeholder
This is the only AR-15 part that would legally require a background check in USA. If someone has a 3D printer they could print one, though I don't know how well it would work: http://www.thingiverse.com/thing:11770This^ .. there should be an open project to reproduce every part. Was thinking something like a glock would be easier to start with though. I'm not aware of any 3d printing methods capable of producing a working lower. At least not working in the sense that you could use it more than once. I don't think that even laser sintering is up to it just yet. Maybe in a few years. If you are going to do it yourself today, you want to go here and read up while you wait for your Sherline to ship. |
|
|
|
Am I correct in thinking that p2pool now provides variable size shares? Will shares found that are higher than the current (network) difficulty automatically scale, or does it need to be set in advance?
Well p2pool has always supported variable difficulty shares. This simple lets you set a higher than minimum diff. You would need to set it ahead of time. If you don't cheating is trivially easy. Look I just found a diff 200,000 shares woot. I get credit for 40,000 shares! Yeah, that's what I was getting at. I just didn't want to spell it all out in public until I heard from forrestv that it was taken care of. |
|
|
|
what is happening is definite proof that bitcoins are a commodity not a currency.
[Citation needed] |
|
|
|
The transition ~40 hours ago went better than expected. Thanks to all for upgrading.
Now that we're using the new implementation, miners can volunteer to raise their share difficulty by adding something like "/1300" to the end of their miners' usernames. The 1300 is the difficulty of your own shares, and can be changed but must be higher than P2Pool's difficulty (currently 650) to have any effect. I urge anyone whose variance is dominated by P2Pool's block finding to try this (which really means anyone who gets more than a few shares per hour). This has the effect of lowering P2Pool's difficulty for the benefit of small miners, which may let P2Pool grow further.
Last, a side note (mainly to DeathAndTaxes): I just pushed a commit that will add another option ("+1") that lets you choose your pseudoshare difficulty, so you can fix it to some value.
Am I correct in thinking that p2pool now provides variable size shares? Will shares found that are higher than the current (network) difficulty automatically scale, or does it need to be set in advance? |
|
|
|
|
The worst part is that I don't think that anyone can stop such a service from existing. Misguided as it may be, enough people are going to want it.
|
|
|
|
|
But if you are putting nLockTime back into the system, why not sequence numbers too? And why should the provider have to wait out the lock on TxA to collect his earnings? Wouldn't the lock make more sense on the transaction that can be replaced than on the transaction that is fixed?
|
|
|
|
I agree that transaction replacement is useful to prevent coins from getting lost/nuked. This is why my version of the scheme requires the vendor/provider/AP/etc. to also put up collateral. It's motivation for both sides to eventually get a transaction signed. If the two parties don't agree, they both lose money and all our coins end up more valuable. AP operators would quickly notice if their bandwidth sales software started losing money rather than making it.
Why not just stick with the solution that doesn't require anyone to put up collateral? |
|
|
|
Likewise if a friend sends you coins from a webwallet and you return them to the sending address neither of you will have the coins anymore.
This. We need a form letter for these threads. Something like this, but customized for bitcoin. |
|
|
|
|
The scripts do not have any notion of a block number. This is intentional.
You can probably figure out a better way to do whatever it is that you are trying to do.
|
|
|
|
|
However much I want these to be true, I wouldn't read too much into them. They are preprints, and they have been up for years.
|
|
|
|
Nope. Coinbase will never be tainted, since mtGox and such does not consider them tainted. Its possible for to example MtGox to dig deeper into such blocks and check the taint, but that would punish the miner because the miner cannot help that he got a tainted coinbase as reward.
I don't think exchanges like MtGox and such would lock accounts belongning to miners that mined a stolen TX fee. That would be counterproductive for the BitCoin network since it discourages mining. Miners can also not say no to a TX fee, the reward (50BTC current) and TX fee are melted together and cannot be separated without tainting both coins if we were for checking tainted TX fees.
So I agree with you, no taint checking on fee's.
So... All I need to do is modify my mining rigs to launder all of my taunted coins by including (but not broadcasting) transactions spending the tainted coins, but with generous fees. That was sure easy to bypass. |
|
|
|
I too want date for 25 btc
Heh. When I first read this, I thought that you were very lonely, if you were willing to pay 25 BTC for a date. I didn't grok your question until I read the next reply. |
|
|
|
|
A lack of fees doesn't invalidate a transaction, it merely delays it. Assuming that something like this catches on (and I pray it won't, but fear it will), a no-fee return will loiter on the network until someone includes it for free. Some miners will probably even make a point of including them as a public service.
Speaking of fees, how will you handle that? If I spend some "tainted" coins and include a fee, will the coinbase of the block including that transaction be tainted? All of it, or just part? And which part?
(In case anyone is wondering what I mean by that last part, pay attention: coinbases are atomic.)
|
|
|
|
Replacements are not pointless. You need to have the combination of timelocked transactions and replacement to ensure security in some cases. Look again at the example I gave above. For the wireless access example, if you don't do replacements, then you cannot sell access: - User makes a transaction of 10 BTC to a 2-of-2 output with the access point. He sends the hash of this transaction to the AP, which then creates a tx that spends the given output back to the user and signs it.
- User gives tx 1 to the AP which broadcasts it, thus locking in the money.
- The AP and user co-operate to resign versions of the second transaction in which the balance between the APs output and the users output is the amount to pay. Because it's just a signature and there's no need to broadcast/wait, the value can be rapidly adjusted, like for every kilobyte of data transferred.
- To be secure this scheme must create the transactions timelocked and use sequence numbers so each adjustment to the value of the contract has a higher version number. Otherwise the user can broadcast the initial payment tx (the one when they hadn't bought much/any bandwidth) before the trade is finalized, thus taking back their money and leaving the AP out of pocket.
Is it clearer now? With replacements the AP doesn't have to worry about the latter scenario. If the user broadcasts the initial payment tx even after payments of greater value were signed, it just broadcasts the last transaction it saw which overrides the users broadcast. The time locking gives a window in which there is time for the network to be presented with newer versions of the same transaction. The output of the setup TX should require *both* parties signatures to spend. The user can't broadcst anything himself. Rather, every so often, the user makes a new TX spending that output, splitting it between himself and the provider. These are not updates; they are separate TX that happen to all spend the same output in different ways. The user signs them and then sends to the provider. Again, the user can't broadcast them because they lack the providers sig. Now the provider just maintains the user-signed TX giving him the most money(the most recentvone). When he's ready, the provider takes the most favorable TX he's seen, adds his sign, and then broadcasts. Unless the provider decides to hold the deposit for ransom by refusing to sign and broadcast until the client pays 50% of the remaining balance... In Mike's scenario, the client retains control of his money until he has proof that his deposit will be returned. |
|
|
|
|
Show Posts
