So, you're also going to be offering your free services to help unstick transactions from people's wallets when they make ones which will _never_ become confirmed?

Because doing that is a pain, and that pain is why the fees are enforced for borderline transactions.  Otherwise people are going to be rightfully mad at you when your software causes them to lose small amounts of bitcoin forever.

Moreover, your claim that most miners will honor these transactions is patently false. It's not hard to find transactions that very few will honor and that almost no node will forward.  For example, send 0.0001 BTC with no fee or 10x reduced fe.


This is silly. The way the dust spam logic treats insufficient fees as non-existent. Simply reducing them by 10x isn't really any better than not paying them at all,  unless you're fortunate enough to manage to connect to eligius (which has a mandatory fee on every transaction but only a very small one). In that case you might as well just apply the eligius fee rules directly.

You've also failed to completely remove the need for fees, but I'm not going to show you what you missed, lest you footgun yourself and others even worse.


If you don't understand it then it is exceptionally irresponsible of you to modify it and encourage other people to run your modified version. Screw yourself, if you like, but not other people.  I hope other folks here are smart enough to not run code from someone who admits that they don't know what they are doing.

The relay and mining rules of other nodes is the only thing that protect them and the network from penny flooding attack. You can't change those except by convincing them to run software that you've made vulnerable.

The fee rules are there so that a consequence of the relay rules of other nodes you don't end up losing bitcoin because you have a stuck transaction that never confirms.  This isn't hypothetical, it happens to people, and it was in response to this that the minimums were setup for transactions that will very likely have forwarding problems.

The crappiest thing is that your patch will end up screwing people with the least ability to deal with it. Those of us with mature wallets with well aged inputs and enough bitcoin to not be doing bitdust transactions pretty much never run into needing fees, patch or not. Instead the people who will get screwed are newbies who won't even know where to get started in recovering coin lost due to forever non-confirmation.

This seems to be pretty narrow: http://eprint.iacr.org/2009/363.pdf (linked to by some troll in #bitcoin-dev 0_o)

But I think that it's enough evidence that giving a third party the ability to control the input to ECDSA is bad. Because the hash function is in the way, an attacker probably can't find two messages that set the signature input to the right values for any attack likely to exist, but I'd much rather that he have no ability to perform such a search at all.

Instead I propose:
ECDSA_SIGN(SHA256(fixed_string+128_bit_nonce+message))

Where the nonce is selected by the signer at sign time, and is included with the signed message (just pack it into the signature).  The space it takes up could be recovered by not including the public key (which can be recovered from the signing address+signature, making it actually less data than the existing patch. Also... Hex?  it would be much smaller base64ed). This also covers the Zebedee attack, actually somewhat better because Zebedee has to attack each signature one at a time rather than each signer, I think this also solves the plaintext TX matching hash attack of Bytecoin above in a simpler and less overhead generating way.

The nonce may also prevent replay attacks in some places where the signatures might be used. E.g.  sign("Release my stored funds")  and someone intercepts it and sends it again later. Such systems ought to force the message to contain an anti-replay cookie, but we get one for free as a side effect.

Congrats, you're finally as fast as phoenix / phatk for me— actually about 0.4% faster it looks like.  (Only tested it on the 5850s with SDK 2.4 so far)

I seemed to be getting high stales with -f0, -f1 was fine but it could have just been bad luck. There didn't appear to be much if any hashrate difference, so I just left it at 1%.

Still need the ability to loadshare (ideally) or fail over between multiple pools.   But it's looking pretty good.  Good work.

The poo doesn't get bigger due to magical pixie dust. It gets bigger due to hashpower being added, same way solomining gets biggerr.


By using the words "on average" you make your statement completely incorrect as many have pointed out here.

It's fine to say that there is increased risk of higher or lower payouts, and the low payouts matter more to you because they'll put you out of business (or the higher means less because you somehow don't need more coin(??))... and thus on average solo has lower utility for you, but that lower utility != less btc _on average_.

You know that the last four rounds of sha256 can be eliminated when mining, right?

Not news: http://forum.bitcoin.org/index.php?topic=11551

On this subject, I've seen people hating on bitcoin7 for using "float" on IRC a bunch— but it turns out that they are using decimal float, which is perfectly fine and reasonable for this. Only the use of binary float leads to perplexing results with bitcoin values.

Hm? it reduces variance vs solo by an enormous factor. This might not be all that helpful for joe-random cpu-miner, but for someone with enough power that they might even think about running solo its _very_ attractive because it reduces the variance enough to make 'solo' perfectly reasonable without the negatives of the pool system— poor reliability, fees, cheating (by operators and other users), and power consolidation that endangers bitcoin.

The payout system implied by this makes it automatically not so great for aggregating lots of tiny users. Were you to increase the number of shares so that most slow users would get one every block then you'd end up with massively bloated blocks, and also a lot of people with micropayments that cost them more money to use as inputs.

Moreover, centralized pools themselves could be participants in this scheme, so smaller pool operators would have less variance disadvantage vs big ones, so even the pooling that remains could be more distributed and competitive.

 

Absolutely, but this doesn't eliminate the value in having the system support higher confidence absent trusted parties.  They'll still be business there in a system where clients can cheaply do more validation alone, but it will just be business for the value you can offer over and above the fully distributed system (faster, immune to some attacks, SLAs, etc).  The suggestion I'm making is still vulnerable to DOS attack, and feeding (mildly) stale data, and it requires more data (the tree fragment).

E.g. a system where you ask trusted parties for a signed statement about the transaction and then after getting it randomly also query for the tree to _prove_ it with reasonable confidence, then automatically announce loudly to the network when you detect lying, along with the cryptographic proof of the the inaccurate response— is a much more robust and secure system than "manually add a bunch of trusted parties; only find some were compromised and screwing you weeks later"... and also more costly since there would be no low cost alternative to trusted services (only run your own full node).

I'm quite concerned that during the last week while mtgox has been down people have been very actively stealing wallets. We've seen many trojans and other wallet collection scams.  Perhaps people took less care to make sure wallets that had little/nothing in them were not stolen.

If someone made a copy of your wallet this week they may be sitting on it hoping that when mtgox comes up you'll withdraw all your BTC and as soon as they see that transaction they'll launch a matching transaction to give all that coin to them. Even if your wallet had nothing in it before, if someone copies your wallet they will also gain access to future payments to the addresses in it as well as 100 future addresses (which are pregenerated and hidden).

If there is _any_ chance that your wallet has been compromised, do not deposit a bunch of coin in it. Instead make a new wallet or cycle out your old keys by hitting getaddress 101 times before using the next address. Make sure to update your backups too.

Stay safe!

Hm?  I'm not asking for proof related to unconfirmed transactions, I'm asking for proof related to previously mined transactions with outputs which have not been redeemed as of the completion of a particular block.  This should be a deterministic product of the block-chain and identically available to every full node.

I think your solution for namecoin is a non-solution because it makes it not a distributed system. You have to trust that the data has not been manipulated in some impossible to validate way.  The is also practically true of the software as whole, but only because everyone isn't actually going to review the whole thing, not because they couldn't review it.   With the tree solution I described you could randomly spot-check such summaries automatically, making them much less risky.

For namecoin, It's also not a solution because knowing the complete state of the system going to be too much work for most namecoin users and it's also pointless.


I want to know for sure what foo.bit resolves to. I don't have the full history (because I don't need it and can't afford the enormous required storage) so I can't tell on my own.  I ask my peers about foo.bit.

They tell me that foo.bit is 1.2.3.4 and that the last update to it was mined in block 100,000. We're currently at block 120,000 (or so say my peers).  With the current pruned tree stuff I can tell for sure that it really was mined in block 100,000,  but I _can't_ tell if it was updated after that since my peers could trivially by sibyl attackers. (If they lied about the chain height and just claimed we were at 100,000 I'd know because I'd notice if my clock was six months off)

If there is a commitment to the open transactions I can ask single peer for the merkle tree fragments from block 120000-199994 for the relevant open transaction (hopefully most of the tree would be the same in those blocks, reducing the data sent) and then be sure that either I got the correct result, that I got a slightly stale result (e.g. it was updated within whatever amount of lying about the height I'd fail to detect), or that my attacker has a serious amount of computing power being employed to give me a stale result about a name.



If you have the block headers (which are quite small), then your trust is limited to that your peers aren't lying to you about the block height and aren't telling you only about some fork.  But you can trust that such a fork would not be very long due to the extreme computational cost, and that the block height could not be too outrageously wrong because you know the current time. 

The fact that peers can DOS attack you by denying you information can't be avoided but it's also detectable and once detected you can try to seek more peers or at least refuse to do anything stupid.


Asking multiple peers is a good and fine thing, but it has _serious_ limitations.  Attackers can often control your network connectivity, so they can simply make themselves all your peers an you have no way to detect this.  Even without network control a sibyl attack can be quite effective: by running thousands of fake peers on a few hundred networks (e.g. just by having simple proxies on those networks) you will very likely end up as all the peers of quite a few nodes.  Querying many also results in N-fold increases in network load.

If a client can use the blockchain proof of work to prove most of their required data, then it only needs to consult multiple peers to obtain confidence about the true identity of the highest block, and attacks performed against this clients are limited to attacks about the content of very recent blocks.

I think this is a beautiful system, but I have a suggested improvement.

If the block is found in the first 599 shares, it should be payed to a multisig escrow. Like this: https://github.com/bitcoin/bitcoin/pull/319

The keys in use could be held by either a collection of parties (reduced trust centralized) or, better,  by a large deterministic random subset of the P2P nodes.  E.g. Take all of the nodes who were paid in the last round and use the block hash of the last block to pick 21 of them (or all of them if there are fewer), and require >50% to sign the transaction releasing the escrow to the appropriate receivers.

I believe this would completely decentralize it while preserving the other properties of your system.

As I understand it,  in lite mode you can validate that a transaction is in a particular block, but you can't validate that it hasn't been redeemed by a subsequent block.

This has a couple nontrivial consequences.  For example, a lite mode client can't tell if a transaction its been told about is even _possibly_ valid or if it is completely jibberish until someone mines it.   

This also means that you can't make a zero trust lite mode namecoin resolver because the only way to be sure that a later transaction didn't transfer the ownership of a name to someone else is to have reviewed the entire blockchain and made your own summary of the open transactions. You can't ask a peer to do this for you unless you trust them not to lie.    I think this is not just a namecoin issue, I think it also impacts various distributed contract proposals that require you to be able to see that a transaction is mined but not yet redeemed.

What if the coinbase TXN included the merkle root for a tree over all open transactions, and this was required by the network to be accurate if it is provided.

Then if you wanted to validate that a transaction was really open, you would obtain the block headers, then obtain the N most recent blocks, then ask an untrusted peer for the pruned open-transaction merkle trees leading to that the transaction in question.  You are now sufficiently confident that the open transaction is still open as of the height of the blockchain you have access to.

Since full nodes must already keep track of all open transactions for validation, maintaining such a tree would be relatively cheap (log2(n) for single updates, fewer per update if more than one txn changes at a time).

Beyond the namecoin/funky distributed contract case/ this would also permit semi-lite clients which track only the headers and open transactions and are allowed to forget about very old open transactions because they can be reminded of them by untrusted peers but can still do full validation.   This might be helpful for network health in the future (e.g. keep track of only recent, likely to be quickly redeemed transactions, and give them forwarding priority. If you can't validate a txn give it low priority, if its children show up again and keep bothering you, then ask a full peer to prove to you that they are are valid and then add them to your cache)


So, can someone please correct my understanding of the system if I'm wrong?

It's still segfaulting for me deep in the ati opencl code during the setup of the second card in a three card system.

It's also quite possible for a pool to never mine a block (or to mine far under the expectation), it's just less like just as it is less likely for the pool to do superbly well.  Worse, because of downtime, fees, cheating, etc. the pool is expected to average less overall. The the reduced variance is a real and useful result, but don't exaggerate the contrast.

Yep. That is the compromise.  The current wallets unsteal themselves.

My arguments:
(0) In spite of recent concerns, I think that loss is a greater risk for most users than theft.
(1) People frequently reuse addresses today, this eliminates the unstealing advantage.
[And, in fact, someone on IRC was just asking about changing the client to send change back to the original address in order to make backups more effective]
(2) Encryption makes theft less likely than it has been
(3) Thieves know about the unstealing property and will already act fast enough if coin is available.  If you're about to receive a lot of new coin you could start a new deterministic wallet. Also after compromising your machine once the thieves will likely leave backdoors in any-case.

If the interface allowed you to have multiple deterministic wallets at once (or just multiple key-heads in a single wallet) you could periodically trigger the creation of a new one in order to get the forward privacy, and you could do this in time with your backup schedule so you're not left surprised by a backup that failed to grab all your addresses.

diff --git a/ocl.c b/ocl.c
index 4173026..a8240eb 100644
--- a/ocl.c
+++ b/ocl.c
@@ -425,7 +425,7 @@ _clState *initCl(int gpu, char *name, size_t nameSize)
                        return NULL;
                }
 
-               clState->program = clCreateProgramWithBinary(clState->context, numDevices, &devices[gpu], binary_sizes, (const unsigned char **)binaries, &status, NULL);
+               clState->program = clCreateProgramWithBinary(clState->context, 1, &devices[gpu], binary_sizes, (const unsigned char **)binaries, &status, NULL);


Meh. Makes it not crash, but it's not sufficient for it to work right. I should look at this after sleeping.

Testing on a silly nvidia machine:

Selected 0: GeForce GTX 275
[2011-06-23 06:00:58] Preferred vector width reported 1
[2011-06-23 06:00:58] Max work group size reported 512
[2011-06-23 06:00:58] cl_amd_media_ops not found, will not BFI_INT patch
initCl() finished. Found GeForce GTX 275
[...]
[2011-06-23 06:04:18] GPU 0 found something?
[2011-06-23 06:04:18] No best_g found! Error in OpenCL code?

Looks like it never accepts results from the GPU. CPU mines fine.


on a system with 3 5850s:

(gdb) run -t 6 -a 4way --url http://pool.bitcoin.dashjr.org:8337/ --userpass 15xWuDHSyKzpvp6FacGKXijBeaaaYhKWSi:x --retry-pause 1 -r -1 --intensity 16
Starting program: /root/gm/cpuminer/minerd -t 6 -a 4way --url http://pool.bitcoin.dashjr.org:8337/ --userpass 15xWuDHSyKzpvp6FacGKXijBeaaaYhKWSi:x --retry-pause 1 -r -1 --intensity 16
[Thread debugging using libthread_db enabled]
[New Thread 0x7ffff4141700 (LWP 17510)]
[New Thread 0x7ffff3940700 (LWP 17511)]
Init GPU 0
List of devices:
        0       Cypress
        1       Cypress
        2       Cypress
Selected 0: Cypress
[2011-06-23 06:17:35] Preferred vector width reported 4
[2011-06-23 06:17:35] Max work group size reported 256
[2011-06-23 06:17:35] Preferred vector width reported 4
[2011-06-23 06:17:35] Max work group size reported 256
[2011-06-23 06:17:35] Preferred vector width reported 4
[2011-06-23 06:17:35] Max work group size reported 256
[2011-06-23 06:17:35] Patched source to suit 4 vectors
[2011-06-23 06:17:35] cl_amd_media_ops found, patched source with BFI_INT
[New Thread 0x7ffff313f700 (LWP 17512)]
initCl() finished. Found Cypress
[New Thread 0x7ffff307e700 (LWP 17513)]
[New Thread 0x7ffff287d700 (LWP 17514)]
[Thread 0x7ffff287d700 (LWP 17514) exited]
Init GPU 1
List of devices:
        0       Cypress
        1       Cypress
        2       Cypress
Selected 1: Cypress
[2011-06-23 06:17:37] Preferred vector width reported 4
[2011-06-23 06:17:37] Max work group size reported 256
[2011-06-23 06:17:37] Preferred vector width reported 4
[2011-06-23 06:17:37] Max work group size reported 256
[2011-06-23 06:17:37] Preferred vector width reported 4
[2011-06-23 06:17:37] Max work group size reported 256
[2011-06-23 06:17:37] Patched source to suit 4 vectors
[2011-06-23 06:17:37] cl_amd_media_ops found, patched source with BFI_INT

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6a2b4b0 in ?? ()
   from /root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libamdocl64.so
(gdb) bt
#0  0x00007ffff6a2b4b0 in ?? ()
   from /root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libamdocl64.so
#1  0x00007ffff6a7a31b in ?? ()
   from /root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libamdocl64.so
#2  0x00007ffff6a225a0 in clCreateProgramWithBinary ()
   from /root/AMD-APP-SDK-v2.4-lnx64/lib/x86_64/libamdocl64.so
#3  0x000000000040793b in initCl ()


Stupid binary libraries.  :-/

Update: Still crashing on the system with 5850s with 181070d129259d088219a0dcd0ef41d9a45439d3

Wtf. Black helicopters much?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I was there.

First the .4242 amount was named by non-mtgox parties (I didn't witness this myself, but talked to the people after who did).  Second the exact value of the txn and destination address were announced by mtgox a long time (probably 45 minutes?) before my node saw the flooded transaction. Apparently MagicalTux had issues getting connections up to a pre .23 wallet.

I consider this sufficient evidence that mtgox still controls that bitcoin.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk4DBmEACgkQrIWTYrBBO/obeQCcC18b82NgtFNlsikTDOPti8Jk
iU0AnjauZYGBQDJqGW+hCxWz14KEuwDJ
=fZrh
-----END PGP SIGNATURE-----

Meh. All this sub-currency stuff is a complete distraction, I think.  How about a pair of new script opcodes:

One signifies an intent transaction which declares an intent to spend particular inputs to particular outputs (and has its own inputs and outputs, but only for the purpose of fees and change).

The other specifies that the output of the txn containing it can only be spent if combined as an input with a matching intent transaction from N blocks prior.  The intent output this transaction must be to the same address(s) as the source transaction so the intent transaction can be effectively replaced by the holder of that key by simply transmitting a new intent transaction that redeems the prior one.

Of course, this doesn't really work for three reasons:

One you noticed:


There is no way to end the race.   If you had a "Safe haven" address that you can trust the attacker doesn't have access to, then you should simply multisig escrow the transaction with that address in the first place and avoid all this stuff.

The second is if the attacker works with miners she can arrange so that the miners mysteriously doesn't manage to hear any of your retractions before it is too late, and the miners can plausibly deny their role in the attack.  They can even learn to do this automatically without prior coordination with the attacker by looking for intent transactions which indicate intent to outputs with large fees.

The third is that if the attacker has compromised your machine in order to obtain your wallet in the first place they will simply make your machine either not see their intent and spend, they will disable the functionality, or they will gobble up the attempted race messages.   They can even do this without actually having the machine itself currently compromised if they are able to gain enough control over the network connectivity:  Nothing in bitcoin today makes control of the network seriously worse than a DOS attack, but in this situation control of the network would completely moot the reversal war.  They could also simply DDOS nodes emitting the reversal TXN off the internet.

Namecoin uses a kind of intent traction to lock names so that people watching the txn flow can't claimjump you, it's quite nice. Unfortunately enabling claim jumping is an entirely different matter than preventing it.

Looking at your slides again I see you say no backup in .23— but the bitcoin has had the backupwallet RPC for some time now.  Is this not exposed in the gui?

I have a cron job that uses backupwallet + gpgs to do offsite backups daily. Works great.