I like the concept, but I wouldn't use it in the present state.    Or would fake the phone number.

Feature Request:  make sharing phone number with your server optional.  Allow parties to exchange this info privately via email when they are ready.

Not everyone wants to share their contact info with a 3rd party in their database.   Even email would be best if it can be exchanged directly p2p and not through server.

I keep hearing the streaming service used as an example, but is there any evidence that people actually wish to pay for content that way?

It seems to me that many/most people prefer paying once a month (auto-renew) or once a year for a streaming service and after that it's all you can eat.   Psychologically if I have to pay some precious BTC to watch a movie or TV show, even if I know it is only millibits, I'll normally pass.  This is true also for Amazon Prime, where I watch all the prime content, but have never once paid for the a-la-carte content. 

Setting up the recurring once-a-month plan is typically a one-time event.  There is a mental cost to making spending decisions, so people tend to prefer fewer of them, even ironically if money could be saved the other way.

I think the same psychology applies to the other common example of monetizing web pages ( articles, etc ).   People are used to stuff being "free" and there is enough content available and attention spans so short that I question the number of willing buyers. 

Browser / advert integration such as Brave is interesting... they could use Lightning micropayments to the end-users for viewing adverts. 

Where I could also see it working is for playing video games.  Though even in that industry services like Steam are now offering all-you-can-eat, as I understand it.

It will be interesting to see how it all plays out, but I certainly wouldn't stick all my eggs in the micropayments for content basket.

Segwit may provide a bump, but the next wave of serious bitcoin expansion will probably take place once Lightning Network is in place and well supported by most toolchains and wallets.   At that point, scalability concerns should mostly go away and high volume businesses/industries can begin onboarding.   Until then.... hodl.

The simplest response to Roger's essay is this:

Consensus layer changes only happen if there is widespread consensus that the change needs to happen. Increasing the blocksize is controversial.  It does not have consensus and likely never will.  Therefore, the blocksize limit will not be increased.

If this doesn't work for you, try the chunked ethminer I posted above.

I suspect OP is a PAID troll.   added to ignore list.

anyone having DAG alloc trouble with older cards, see here.

anyone having DAG alloc trouble with older cards, see here.

I fixed it!   at least it works for me.

I was having the same problem with a couple R9 270s and even (sometimes) a 7970 3Gb card.

I created ethminer-genoil-chunked: a fork of genoil's miner (from March) that includes a patch from equinox for chunked mining.  (The patch was for official ethminer but was never accepted.)  All my GPUs are busily mining eth again.

Sorry, no binaries.  You will need to compile it yourself.  Instructions are in the README.

happy mining.

it's not exactly what you are asking for, but bitprices can show you all transactions and a total balance for all the addresses with historical prices, as if they belonged to a single wallet.  ( even if they don't. )

There is demand for DAG chunking support right here!     My R9 270 cards can't load the DAG and I've tried every single recipe for env vars.

Is your Apr 15 chunking code committed somewhere?   I cloned your github repo and searched through every branch but I can't seem to find it.  I did find some commented out code with a comment that it is disabled because chunking never finds a block.  I uncommented it, and now at least the GPU is hashing, but yeah so far not seeing any shares.

I can't run your binaries because I'm on linux.  But I can build from source no prob.

kinda stuck at this point, help appreciated!

EDIT:   The card just found a successful share!  happy day.    The GPU is running slower than I expected, about 12 Mh/s vs 18 or so for my 7970s.

In the spirit of "Coinjoin that people will actually use", I'm wondering if any of the regular bitcoin wallets have integrated joinmarket, or have announced any plans to do so?

Along these lines...

Is there a joinmarket API that would make it straightforward for a wallet to integrate?

Has any effort been made to approach wallet makers?

If not, perhaps we should open issues requesting joinmarket support on their respective github pages.

Perhaps it can be done.  But it doesn't interest me.

1)  immoral.  Voting by definition implies imposing one's values onto others and limiting their freedoms by way of government force.   In a free society, voting would be a useless act as the government would have no power in the first place.

2)  statistics.  Except in small local elections your individual vote is basically irrelevant.  statistically insignificant.  People have a greatly inflated sense of "how much is my vote worth" that does not correspond to reality/math.  Sadly this gives rise to "I will vote for the lesser of two evils" instead of "voting my conscience" because "I don't want to waste my vote".  This flawed thinking maintains the status quo.

Hi, I found the output of wallet-tool.py hard to read so I made a patch that formats the output into text tables with borders.

Here's a very basic example:


Wallet addrs and history are also in tables.

Pull request is here:  
https://github.com/JoinMarket-Org/joinmarket/pull/539

If anyone wishes to try it before the pull request is approved, you could clone from my repo at:
https://github.com/dan-da/joinmarket

thread fail.

I get the feeling that this thread is pure FUD. 

But what if it wasn't?  What if CoinBase disappeared next month?

Bitcoin would go on.  It might take another reputation hit and a price hit.  Maybe VC funding dries up and bitcoin stays low for months or years out of the mainstream, forgotten by the media.

I think that might be a great thing.  It is much better for bitcoin to spread organically, person to person, peer to peer.   With people learning and holding their own keys rather than blindly trusting yet another bank that acts like big brother: papers please, oops sorry your funds are frozen.

Meanwhile, scaling solutions start to come online and mature.

I wouldn't miss coinbase at all.

sad.

The question is:  why is the OP using coinbase at all?   hasn't learned his (or her) lesson yet I guess...

zero confirmations make it suspicious.  period.

solution:  wait for at least 1 confirmation.  more if high value.

otherwise if you feel you must accept zero conf, then I would think the most cost effective manner would be to (a) put a limit on the highest value tx you will receive with 0 conf, and (b) track the number of double-spends you encounter along with the avg amount lost and factor those into your business model.

or just:  wait for lightning network to mature.

With bitcoin-cli you just call sendtoaddress or sendmany with the tx amount and the software will automatically calculate the necessary fee.  You can retrieve the amount afterward with gettransaction if you need to record it.

Also you can call estimatefee before to get an estimate, but it could be different from the actual amount used due to changing network conditions, etc.

If you absolutely insist to control the exact fee amount yourself you would need to use createrawtransaction, signrawtransaction, sendrawtransaction.