Works now, thank you.

I was able to create a wallet just fine, but when trying to claim, I get "Unexpected error. Try it again later or contact our support. Thank you." What do?

Just to gauge interest, would anyone want to to do a similar deal with me for 300 BTC/BTU? I get your 300 BTC, you get my 300 BTU. I don't think it's worth bothering until the BU hashrate gets above 50% (unless you want to make "does a fork happen" part of the bet), but I figure I may as well start asking around.

I've been thinking about doing something similar, but on a much smaller scale.

For the swap, you should be able to use the taint method so that the BTCs and BTUs get to their proper destinations:

• Before the fork, you each depsit 60k coins into a multisig address, for a total of 120k
• After the fork happens, the escrow address will contain 120k BTC and 120k BTU
• You obtain a properly split (non-replayable) BTC UTXO on the Core chain, and Roger obtains a properly split BTU UTXO on the BU chain
• You send your BTC UTXO to the escrow address, and Roger does the same with his BTU UTXO (let's say they're 1 BTC/BTU each)
• The escrow address now contains 120,001 BTC and 120,001 BTU
• Create a multisig transaction that will send the original 120k BTC plus the 1 BTC TXO to an address you control, get it signed, and broadcast it to the Core network. This transaction will be unspendable on the BU chain, due to the 1 BTC TXO.
• Create another multisig transaction that will send the original 120k BTU plus the 1 BTU TXO to an address Roger controls, get it signed, and broadcast it to the BU network.  This transaction will be unspendable on the Core chain, due to the 1 BTU TXO.

While it isn't unheard of, it is fairly rare for open source projects to revert to being proprietary. Most high-profile instances of that happening have resulted in the project being forked and the original maintainers losing control of it. So no, it's not unreasonable to expect an open-source project to stay that way.

In this case, while I'm hoping that an effort to maintain the LGPL version of the Trezor firmware will take off, I suspect that the project may be too small at this point. The Trezor's install base isn't very large, and additional people likely to participate in such an effort are now unlikely to buy a Trezor.


I did buy an open-source hardware wallet. That's the basis of my complaint.  ಠ_ಠ

What's the deal with this?:

Trezor Code no Longer LGPLv3, but now more restrictive Microsoft Reference Source License

I bought my Trezor with the understanding that all of the code running on it was open source (Free/Libre/etc), and would continue to be.

If the code is going to be under a restrictive license going forward, I am no longer interested in owning a Trezor; I request that SatoshiLabs allow me to return mine for a refund, in order to make up for the bait-and-switch.

Remove the FRR option from UI and API, and just let existing FRR offers run their course.

You could either turn off autorenew on those offers, or just wait for lenders to gradually do it themselves.

Do you understand the point of having a well-filled order book, In general? You don't seem to.

Margin traders should really be the ones taking you guys to task for this, since they're affected far more than lenders are. The issue is just more visible to lenders.

If you set autolend to a low enough rate, it should act like a market offer and pair you with the highest swap demand that's currently on the book.

Alternatively, you could set up my bot or HowardF's bot, and let the bot manage lending for you.

That would depend in large part on what minimum rates people set. The default minimum rate on MarginBot is 0.05% per day (18.25% per year). The non-configurable minimum rate on FRR loans is 0%. If you were to switch all current FRR auto-lenders over to using an aggressive undercutting bot with a non-configurable 0% minimum rate, then yes, they'd clear out all the swap demands on the book and make it so that no offers above 0% get taken except when there's enough demand to bust the wall.

Of course, gradually the auto-lenders would log in, see that the party is over, and withdraw their funds. This would allow rates to start rising again; possibly quite rapidly, depending on how many fixed-rate lenders called it quits too.

Whatever you guys do about the FRR situation, I would strongly encourage you to require auto-lenders to explicitly choose a minimum rate for their offers. Providing a default risks recreating the wall at that rate, or at least distorting the market towards that rate. You may also want to consider allowing (or requiring) borrowers to explicitly choose their maximum auto-borrow rate (instead of the current fixed %1 per day), so that we better incorporate borrower preferences as well.

Having thought about this some more, I'm going to take my own advice and remove the default minimum rate from my bot, and require users to set it themselves. HowardF, you may want to consider doing the same with yours.

Well, no time like the present:

cascadebot: A simple (but effective) lending bot for Bitfinex

deleted

Speaking of bots, I'm testing one that I just wrote (to be released soon), and I'm getting "Max retries exceeded" way before hitting the 60 requests per minute limit specified in the API documentation. The strange thing is that the bot has been running fine all day, but choked twice in a row just now. Is there some other hidden limit that I'm running afoul of?

EDIT: Nevermind, it looks like it was just a regular connection error. Wording of the exception threw me off.

Most lenders will not use that bot, and will instead opt to use whatever on-site autolending facility Bitfinex provides.

That said, if everyone did start using that bot, it would be a great improvement over the FRR. MarginBot places a range of offers, rather than dumping everything at a single rate. You can configure a minimum rate to lend at, as well as an amount of your funds to reserve for lending at higher rates. Everyone using it would configure it with different parameters to suit their tastes. We would no longer have the massive, market-distorting wall of offers at a single point on the offer book.

That would be the same as offering your swaps at a fixed rate of 0%. It seems like very few people if any would choose to do that. When was the last time that the USD swap book had no demands on it?

After thinking about it some more, I like my second idea better, though:


Offers slowly cascade down until they reach the current supply/demand equilibrium point. As demand for swaps rises, it pushes that equilibrium rate up. As swap supply rises, it gradually pushes the equilibrium rate back down. You could set everyone at a default of x=1%, y=0.1% (per hour, or 0.00167% per minute), z=0.05%, and let people fiddle around with it from there. With those settings, your offers usually won't sit idle for more than 10 hours, which is probably better than the FRR on average. When demand goes crazy and the offer book gets cleared, your new offers start getting filled near %1, which they'd never do if set to the FRR.


This would cause FRR offers to sit idle for even longer than they already do, and doesn't remove the wall. It's less bad than the current FRR setup, but still has the same primary weakness: spikes in demand aren't apparent until the offer book has been entirely cleared out. The wall is allowed to float up slowly, but the price (interest rate) signalling mechanism still gets suppressed. The main benefit of your proposal would be that it'd make the FRR less attractive to lenders. May as well just remove the FRR and its distorting effect entirely.

Here's an idea for replacing the FRR while still catering to lazy lenders.

When choosing variable rate autolending, lenders will have two parameters to set:

• Allow no more than $x of competing offers to be priced lower than or equal to mine
• Do not reduce my offer below y%

Do not provide default values.

The system should place the lenders offer as high as it can without violating the specified parameters. If two competing offers would end up in a race to the bottom (for example, x=0, y=0), just match them with the highest available swap demands.

This would break up the massive FRR wall while still allowing autolenders to benefit from increases in swap demand.

An alternative that might be simpler to implement:

• Place new swap offers at x%
• Reduce swap offer rate by y% for each hour(or minute?) that it remains unfilled
• Do not reduce swap offer rate below z%

This one also has the advantage that default values can be provided, since it will still create a range of offers even if everyone uses the same parameters.

Do you have any evidence of that, or are you just speculating about motives?

You can always set auto-lend at the lowest fixed rate you're willing to accept, which will then match the highest available swap demand. This may even be a better deal than the FRR for smaller lenders, since their funds won't end up sitting idle.

That said, I'd like to see better options available for lazy lenders. I am one, after all.

The problem with the FRR is NOT that lenders aren't getting paid enough. It's the fact that it renders swap rate useless as a market signalling mechanism. If swap rates are prevented from rising, there's nothing to draw in more lenders to make more offers. Potential lenders don't know that more funds are needed until the offer book is practically empty.

Currently there's no support for the Trezor in the wallets that people are used to using, thought that'll change eventually.

I wasn't in a huge rush to order a Trezor for myself because I'm reasonably able to secure my coins, and didn't feel that they were at risk. The main reason that I picked one up was more so that I could evaluate it and decide whether to start giving them as gifts to friends and family that use Bitcoin.

Speaking of, any plans for a Black Friday discount?

That's normally how signing works (with PGP, and I assume with other systems as well). Does signing a message with a Bitcoin private key not create a hash of the message as an intermediate step? Or is the Trezor implementation missing that? Is there a specification for how message signing and verification should be done?