If there are things that the new GUI does poorly, please open issues on them: https://github.com/bitcoin/bitcoin/issues

There are many people willing to work on and maintain the QT interface. If there are objective weaknesses that are bugging you they will probably be fixed. (On matters of taste— well, no promises... Its no good making one user happy only to make another unhappy).

No one is maintaining the WX gui anymore.  No one is willing to do so. It's even a pain to build.

I have a simple protocol here for private messages associated with transactions which can only be read by the reviver. This would allow inband broadcast green addresses without compromising privacy or bloating the blockchain:

Say we have a TXN(Me->You) with a TXID.  I want to tell you that it was really RealME who created this transaction, even though no one knows who Me is, and I want to do this in a way you can prove to others that RealMe claims to be Me should I screw you... but we don't want anyone else to know otherwise.

So I first send TXN(Me->You) on the network.

I then form a message to be sent secretly to you  Message={TXID,SIGN(RealMe,TXID)}

I then compute Ek = ECDH(Me_private,You_public) and then compute Em = Enc(Ek,Message).

Then I sign Em,  Sig_EM = SIGN(Me,TXID||Em) and finally I broadcast {TXID,Em,Sig_EM}.

Relaying nodes are able to associate the message to a particular recent transaction and only allow one (or a small number) of messages to prevent DOS.  But other than telling that the sender of TXN(Me->You) send a message they learn nothing more.

The recipient of the transaction would see they received a message. They could repeat the procedure, decode the message, and find the signature in it proving that RealMe claims responsibility for the transaction.   Should I cheat them by reneging on the transaction, they could publish the signature to prove my untrustworthyness.

The problem here is that the addresses we send funds to don't include a public key... only the hash of the public key. So I probably don't know You_public to perform the ECDH.   This could be resolved by making an address type with an extra 256 bit compressed public key tacked on the end.  This key would only be used to receive private messages associated with the address.  (This would also have the benefits of working with P2SH transactions, even complicated multisig ones so long as you don't mind that there is a single address which can be used to decode messages).

Such a system would enable some unfortunate additional parasitic applications of the Bitcoin network... but better to have them only ephemerally sending a limited amount of traffic rather than imposing on the blockchain for all time. By rate limiting these messages based on transactions they shouldn't make the situation any worse.

I'm not generally in favor of this at this time.  "Green addresses" add irrelevant bloat to the block chain (no one but the recipient cares about that data, certainly not people 10 years from now) and compromise the privacy of Bitcoin users— even people who aren't directly the users of green addresses.  They also encourage poor key management practices (e.g. keep all your funds on a single green address) or even more chain bloat (by doing two step transactions).

I also understand from talking to Magicaltux that green addresses have not been much of a success.

We added the signmessage functionality so that people could use a well known public key (your green address if you will) to sign any data they want, including transaction IDs, without putting anything in the blockchain or publishing it.    For example, when you made a withdraw from a trusted bank, the bank could use its well known key to signmessage the relevant transaction ID.  It could then either send this signature directly to the recipient if you provided a payment URL,  or provide it to the user as a "confirmation value" which they could carry over to the other side.

Unfortunately MTGOX did not implement the former because they don't want their customers telling them that they're sending funds to $QUESTIONABLE_PLACE, and didn't implement the latter because it's not fully automatic.

I know nothing about the MCMC problems used for physics, but I sure can't see how this can be used for MC sampling for bayesian inference, since you actually need the whole chain data after the bootstrapping. Perhaps it would be helpful if you spelled out some example problems and gave the setups for them.

As someone who uses optimization frequently the idea of being able to buy cycles to run arbitrary stochastic algorithms is a very exciting one. 

In particular, I often use optimization ~interactively while problem solving. While my average utilization is fairly low, I would really like enormous amounts of computation in short bursts. If I could buy EC2 in 5 minute chunks I'd regularly be buying 1000 CPUs worth at a time.  So a distributed system which allowed me to shift computation in time in order to get more of it at once would be _VERY_  useful to me.


I have some vague concerns that the result of the Lua execution engine (with software floating point!) will be that such a system could not be competitive with centralized computational services— simply because you're going to take some large slowdown to start with. You don't seem to have addressed resource exhaustion except for speed, e.g. running the systems out of memory, or simply requiring great amounts in order to disadvantage nodes with smaller amounts creating a race where all participants must have as much ram as the most and making it hard to reason about the returns on investing resources into this system. Yes, participants can use the escape hatch out, but at a 10x disadvantage to ones that have enough ram to keep going.

For the same reason, I'm unhappy with the alternative block regular hash— how is such a system to be competative with 50% deadweight loss (on top of the other losses)?

Bleh.  I wrote several paragraphs of text with excited ideas about this and that— and also arguing that you didn't need the second hash function because if you already had 51% computing power you'd be better off using it to run optimized versions of your own computing work then using it to trick the rest of the network into running inefficient versions of your work.

When then made me realize that your system has a pretty debilitating "Optimization attack"— I'm sure this isn't news to you, thus the every other block optimization... but I don't really think it helps much. I think your paper should spell this attack out clearly.

Say an attacker forms some A() which is just a trivial function e.g. A(x,y)=x, he also forms an A()', say A(x,y)'= sha256^1000(x) * 0 + x which is identical to A() in results but which is much more expensive to compute.  He announces A()' to the network, but detects it on his own systems and runs A() instead. He now has a enormous speed advantage on all other nodes.

The alternative block idea prevents this from being trivially translated into an overpowering attack, though the security is still enormously reduced compared to blockchain cryptocurrencies. But I don't think thats the worse result.

The worst part of this is that even ignoring overpowering attacks, I believe it will be economically advantageous to perform this attack so long as getting the network to use some A() always costs strictly more than the reward. This means that currency will only enter the system through execution of the dummy A that cost no one anything to run, which (assuming constant computing power) means another 2x overhead: for every unit of real work you do, you must have a unit of dummy work to create the coin to run it.

This ... on top of the standing halving required to make overpowering even a little non-trivial.. and the halving (at best!) of using a highly sandboxed execution engine (rather than optimized machine code)....  As a result this system probably has a peak computing efficiency of 12.5%, while offering substantially less security than existing cryptocurrency in a number of regards (the >25% attack, the fact that the POW can be expensive to validate— burdening regular nodes not just mining ones, the fact that the POW might be insecure to validate, again burdening regular nodes and not just mining ones).   For people who don't need to store up computing for burst loads this system could pretty much never be more cost effective then simply computing their desired work directly.

Have I gone off in space here?



In any case, in the chance that this isn't as useless as I now fear, before finalizing your system I'd like to encourage you to take the chance to pick up some protocol improvements which can't easily be implemented in Bitcoin. The anti-timewarping fix would be one obvious one, less trivially, you should probably change to Ed25519 from the secp256k1 curve. There are a number of proposed changes at https://en.bitcoin.it/wiki/Hardfork_Wishlist though many of them would be inapplicable to you or a bit too blue-sky.

I've unsticked this and updated the subject to indicate that this isn't a pool (and thus its hashrate is doublecounted against the pools its actually using) but instead a hopping proxy service, as it's name is potentially misleading.

Lots of gibberish on this thread.    A typical current generation quad core cpu will produce 18MH/s a similarly priced (and higher power consumption) GPU will produce perhaps 320 MH/s.    ~20x is nowhere near 500x.

I expect it to be at some point.

Having two different algorithms doesn't reduce simultaneous block finds, only making blocks further apart does.  


Why does it matter?  For may (most? almost all who aren't stealing power/computing?) people it's long been more efficient relative to power costs to mine bitcoin with gpus and sell for litecoin if you really want litecoin.   I can't see how this would make it any _worse_ than that.  Perhaps efficient GPU mining will take litecoin back from the thieves and make it profitable for honest people to mine again?


So, how much have you placed against this at http://betsofbitco.in/item?id=292  ?   I'd think anyone sure enough to call someone a liar would be willing to put up way more than 1.50 BTC.

The fake compromise announcement earlier caused some careful inspection. Phantomcircuit believes he's found some actual severe vulnerabilities.  Bad day for BTC-E I guess.

Without knowing the details of all he found — I recommend staying logged on of BTC-E when you aren't using it, and only visiting it with a clean browser which is not concurrently viewing other sites.

So how much have you put in at betsofbitcoin?  Such certainty was surely matched by a large bet, no?

This is actually pretty much crap, for this purpose at least— the idea that you _only_ need time stamps means there there no way to produce a (even semi-)secure lite resolver: every node would have to evaluate the whole history for itself because anyone could add rules violating commitments later (e.g. registering an already taken name).  This is one of the reason bitcoin nodes validate the txn they include rather than just timestamping them and letting everyone sort out validity for themselves.

It's also really unfortunate that they promote a completely unscalable commitment scheme which requires O(N)*bitcoin_nodes storage, bandwidth, and processing when O(1) commitments are perfectly possible in Bitcoin— which is what merged mining uses.

PPLNS is awesome.  But P2Pool is PPLNS, so as a PPLNS pool it's more redundant to P2Pool than it would be otherwise. Some people prefer other schemes (e.g. PPS) that aren't reasonable to provide with P2Pool.


Sounds like a feature request.

I assume everyone who called this a scam will but picking up some easy money at http://betsofbitco.in/item?id=292

Right?   Or did you call someone a fraud and a scammer for something you're not even sure about to put a little coin behind?

Fft.  With P2Pool for litecoin cooking, why another old centralized pool, especially a PPLNS one?

Ah.

What you're having happen there is that when you send your transaction is dropped by the network— lacking the required fees because it looks like a DOS attack (fast turnaround)—, but after every block that doesn't contain your transaction the client tries retransmitting it (with a random delay).  After two hours or so, the input coins have matured enough that they no longer require a fee.  After that when your client resends then it goes through.

If you'd just waited the same time it would have sent without a fee in mainline.  From a usability perspective, when the times are reasonably short, it might be better to wait like that... but if you shut down right after sending the transaction will be stuck until you start back up and wait an hour or so, and a lot of people do that.

I've had transaction queuing on my feature wishlist for a while (mostly for the purpose of automatically grouping transactions into a sendmany). Perhaps that would be a good way to address this.

FWIW, you can do this testing with Testnet too. So you can do a bunch without having to move around a bunch of real bitcoin.


I don't know about you, but I usually skip to the end of long threads and don't bother reading much of the start.

Yes, and they are also seldom added in those cases. Moreover, The amount of the transaction itself isn't whats relevant for the fee calculations (unless it goes under 0.01 BTC).

I'm just stating a simple fact: The bitcoin software uses the _same_ code to determine if fees are required for relay as it does when adding fees to a transaction.  If it decides to add one, it's only if other nodes wouldn't have relayed (much less mined) the transaction without them.

Yes, I'm sure you tested and found it worked fine. I expect that in those cases the unmodified reference software also would not have applied a fee.


And freedom you have, there is nothing I could do to take that away from you even if I wanted to, though I don't.
Your promotion on your signature, "Getting robbed by miners", however isn't just about providing a choice. As far as I can tell it's about spreading misinformation, fear, uncertainty, and doubt.  It reduces choice by clouding people's judgement with the fear that they'll lose money and may cause them to run your fork when under a rational analysis they would not.

Your change is also not a 2 line patch. Diffing your RC tag and the reference client RC tag gives me a 289 line diff.  You appear to be missing at least one random patch from mainline in December. I'm sure this was a simple mistake, but what happens when such a mistake introduces a data corruption bug?

In any case, I didn't post for your benefit, we've gone over this before.  I was just making a regular cautionary post so that people who are just seeing this thread for the first time won't jump to the end and miss the earlier discussion.

Or change the threshold to 0: http://forre.st:9332/patron_sendmany?total=1&thresh=0. The default threshold is 0.01 (people who would be paid under 0.01 are in the 'lottery'), because outputs below 0.01 will result in needing a fee.

Since this is back on the top of the forum— it's time for the regular reminder:

This is a terrible patch that puts you at risk and no one should run it.   The overwhelming majority of transactions with the stock reference client do not pay fees, the average _total_ fees per block are about 0.02 BTC— pointing out the lie that miners give a crap about collecting fees from you— the reference client only adds fees to transactions when it would not mine or relay them had they come from someone else, when they are objectively indistinguishable from a DOS attack.  When it does add fees they are usually only 0.0005 BTC.

Recovering from stuck transactions is a major pain and requires careful editing of the wallet binaries.  When a transaction is stuck it may lock up far more than its value.

These patches also don't do what they claim to do— they'll still apply fees in some cases. (Though at least thats a good thing)

It's also the case that no one actively involved and informed in Bitcoin's development is reviewing these patches.  If ShadowOfHarbringer was actually competent do this this work he would not be making misleading claims and would instead be working on code to help users safely recover from stuck transactions.  I would not run code released by him.

getmemorypool now returns a field
    "coinbaseflags" : "062f503253482f",

which is data that can just be stuck on the end of the coinbase.  P2Pool uses it, poolserverj should too.

You're being far too sensitive here, I think.

There has been a ton of fraud in bitcoin services— plenty of people taking whatever coin they can get and running. You can now trivially purchase hashing power on demand.  Pools have been _regularly_ attacked with overt attacks, Eligius is being hit with 20GBit/sec as we speak. The solidcoin people run a pool with the explicit goal of 'taking out bitcoin', complete with graphics that look like they were made by a 14 year old wannabe mob boss. People can now purchase large amounts of hash power at a small premium via services like gpumax.

And, no— there isn't an abundance of hard evidence, part of the reason that pool oriented attacks are concerning is because there simply wouldn't be an abundance of evidence. Blockchain.info's identification is crap except for the few well tagged pools that they identify and can easily be obscured by anyone who wants to try to do so.  Certainly the fact that operators continue to deploy proportional pools that get their non-hopping customers ripped off doesn't bode well for their diligence even if they aren't ever actually malevolent.

Basically it comes down to trust: Do miners trust the pool operators to not attack Bitcoin or other pools, do they trust them to keep their setups correctly running, do they trust them to adopt and correctly implement fair payment schemes, do they trust them to not hand them the dirty proceeds of laundering instead of fresh coins,  do they trust them not to pad the share counts or 'lose' shares, or to simply run off with the miners funds?

Often that trust is justified— it certainly seems to to be in your case. But even so, Bitcoin was created for the explicit purpose of reducing the points of trust we needed to have in our currency system.  Please don't take it personally when people point out the potential weaknesses of all the avoidable trust pooling can add back to the system.