We're adding Slimcoin to BTCpop as soon its synced.

HBN uses a lot of memory, planned to optimize that?

Domain is on auto renew.

I toke over BTCPOP on 19th June 2016 after the previous owner "lost" all user balances.

Btcpop is on 1.9.

Most loans are BTC based.
USD tied loans doesn't fund easly because Investors want to grow their Bitcoin and mostly don't think in Fiat.
In the future we'll have loans in different currencies ( ETH,LTC,Bitcoin Cash,USDT,DASH,Monero  ).

Altcoins can be used as collateral and its investors who decide where they invest at what rates.
Shares ( on pop ) can be used also as collateral.

https://blog.btcpop.co/2017/04/28/how-to-get-your-first-bitcoin-loan/

That was on a Ubuntu 16.04 machine.
Wallet loading on startup need to be optimized as well. Takes very long with a 70MB wallet.

I get boost::thread_resource_error: Resource temporarily unavailable
In first place it didn't build and i had to change:
To:
In rpcrawtransaction.cpp

Bitcoin is not a protected brand at all.
Those claims are stupid, you could say that BitcoinDark and Bitcoin+ are attacks then as well.
What do you say if the 2MB HF becomes the majority chain with most value and Transactions?

I don't think it was spam at all.
With the EDA kicking in on Bitcoin Cash the hashrate dropped a lot and same time the markets was pretty crazy what just caused a lot of transactions.
It was growing all the time and dropped a lot short before the Split on 1st August.
https://blockchain.info/charts/n-transactions?timespan=all&daysAverageString=7
Increased then when Bitcoin was reaching all time highs and then when the fees spiked the amount of transactions decreased again.
It makes no sense that spammers spam a lot when its very expensive but then stop when its cheap. They would start spamming when its cheap and if it would be miners they would just continue spamming low fee transactions to collect higher fees on normal transactions.

With now lower fees the amounts of Transactions is growing again slowly, probably soon the cap is reached again and then the fees will increase a lot again.
High fees causes less transactions, low fees causes more again but lot users will stop using Bitcoin for good as well when they had to pay high fees.

The first time the tx fees spiked for longer Bitcoin lost a lot of market share that made them lower also again.
It was also a time when Bitcoin price increased and was so more used.

I wont suggest to do such changes if you don't fully understand what you're doing.
I'm also waiting for support of different address types as change address ( prefered configurable and don't care much what the default is ).

How is that stealing?
Weak hands will always lose money, thats why they are weak hands.
Enjoy the ride, buy the dips and be happy with cheaper coins.

Has nothing to do with bitcoin but I suggest you look at something like "generated" and ignore those Transactions.
Or just disable staking.

More likely they would integrate Flextrans instead of Segwit.

How would they control the code if Core devs would follow the 2MB increase?
We're far away from not being able to scale on chain and increasing the blocksize doesn't mean there can't be developed on other scaling solutions.
If other solutions works and get adopted then the blocksize keeps smaller or gets smaller again.

But its simple. If majority mines the segwit2x chain then core gave the main coding away.
Nothing stops them from following that chain.

I support bigger blocks. Bitcoin becomes less usable without.
Segwit didn't solve anything so far.
Adoption is very slow and many was ready for years.
I've integrated segwit to our plattform and its mostly done but no one uses segwit so far.
Core wallet doesn't even support it fully.
The change goes straight to a non segwit address, you would assume they would've code something in to enable segwit fully once its activated on the chain.
LN is far from ready and probably will face a lot of problems what might be solved or not.
Bigger blocks much earlier would've make sense and the blocks would've been smaller automatic again once other solutions are ready and adopted.
For now I see those scenarios:
1. Segwit2x become the majority and the 1MB chain will die if no changes made to diff adjusting and no replay protection added.
2. 1MB stays the majority chain and Bitcoin Cash will get more support as the 1MB chain becomes less usable with full blocks and high fees.
3. Segwit2x and 1MB becomes both enough hashpower to survive in this case it would be open what chain will win in the end.

F2pool said they will not support NYA anymore but still signaling. In the end individual miners decide on what pool they mine.
If many miners would disagree with NYA they would already have switched to slush or made new pools.
Till November a lot could change. It will be interesting but is annoying the same time.
The stalling caused a lot damage to Bitcoin already even if the price is high now what could be a bubble as well or not or maybe the price would've been even higher.

There is no technical and no economical reason to not increase the blocksize now and work on other solutions the same time.
Bitcoin Cash was released in a rush and more wallets and services support it already than Segwit and Segwit was ready for years...
Blocksize increasing would require to update nodes, such splits cost a lot more time and work to do.

Oh and the argument that bigger than 1MB blocks would not allow someone to run full nodes becomes annoying also.
With segwit the blocksize could be 4MB and the amount of transactions fitting in a block would only double if all would use segwit.

If 90% or more of the miners supports it then its really core who should add replay protection and change the difficulty adjusting.
Without adjusting the difficulty and without replay protection its most likely that the market will adopt quick on segwit2x.
The mining support could even drop then ( not must ).
It would be in own interest of core to add replay protection and update the difficulty adjusting.
If most miners will not support segwit2x by the time it activates then thats ofc another story.
I prepare for all outcomes but if segwit2x becomes the chain with most hashpower then I'll see that as Bitcoin as probably the 1mb chain will die if no replay protection and quicker difficulty adjusting is added.

Splitting your own coins can be easly done with RBF.
Send with low fee on the majority chain and when its confirmed use RBF to send them with higher fee on the minority chain.

It would make sense to enable it as config option.
changeAddressType = P2PKH,P2SH-P2PK,P2SH-P2WPKH
So users can choose what type of change address they want.

Is there a way to export pre generated addresses from watch only wallets?
I can't pre generate segwit addresses yet on the offline device and I can't find an export function to the pre generated addresses in the watch-only wallets...

Edit:
I removed the checks my self in the source and now I'm able to pre generate addresses on my offline device.

That would mean a lot work to shoot your self in the foot.
Probably harder than sending coins to a wrong address...
Most users will probably just click receive funds and don't change the address type at all and if they do a warning would be enough.
Probably also most newbies will run a current bitcoin node on top with segwit enabled.
I guess users who do non standard stuff know what they do as well.

The worst what could happen is that someone generates a Segwit address and is running armory on top of Bitcoin Cash and sending those to his segwit address.
But that need a lot intention to mess things up.

Would make sense to allow Segwit generation also in the offline version.