looks like pretty steady growth to me.  why the pessimism?

speculators are a part of every economy.  why should bitcoin be any different?

So long as the daily transaction volume continues increasing (or fees, by proxy) I am optimistic.

That's expected.  Any movement that starts small and gains momentum will inevitably be diluted.

This is why it is important to ensure that the core principles/values are correct early on and there is a mechanism in place to propogate them or otherwise prevent against corruption.  Before things start blowing up.

Bitcoin is exciting because it is very good at enforcing the core principles via code and consensus, regardless of what newcomers may want, even a majority of them.

And it got a lot of things right from the start:  immutability (mostly), limited supply (eventually deflationary), basically decentralized, trustless, secure, programmable.

I do worry though that some of necessary "core" bits were not really in at the beginning and are difficult to add later.  These include:   privacy/fungibility, scalability, tx speed,  full mining decentralization.

Fortunately, the core devs seem to agree and are working on all these aspects, as are other projects such as zcash.

I'll wait for the trustless implementation, thx.

It seems to me that this problem can only occur if there is little or no competition for getting included into blocks.

So long as block space is limited and there is significant competition to be included, then transaction fees should be sufficient to support mining at a sustainable level.

time for an update to the OP?

The traditional way is to run bitcoind and query it via RPC.

If you just want a bolt-on checkout module fast, you might want to look at cryptowoo.

Don't forget Dave Kleiman

My layman's understanding is that POS in general has at least one big theoretical exploit just waiting to happen, and it probably will once there is sufficient value on a POS chain for a blackhat to bother coding up the exploit.

So ethereum switching to POS seems like a nice test case of that possibility.    :-)

Anyway, the short answer to bitcoin moving to POS is:  never gonna happen.  too controversial.  changes to bitcoin protocol require consensus.   end of story.

A lot of people use bitpay.  I'm not sure of their policies with regards to "high risk businesses".  A nice feature of bitpay for many merchants is that they can convert the received funds into USD and deposit to your bank account.

Also, Bitpay is a third party, and it is more in the spirit of bitcoin to accept it yourself directly.  

There is a software package for directly accepting Bitcoin called cryptowoo that has a nice feature-set and is well maintained.  It is not free, but is inexpensive and does not have ongoing transaction fees.   note: I am not the author of that package, but I did recently survey all the available open source packages and found cryptowoo to be a superior alternative.

If you are technically inclined, you could install cryptowoo yourself.  Otherwise, you would be wise to seek the services of a professional.

also: Besides cryptowoo, it is not *that* hard to hack together a custom solution that uses bitcoind.  The trickiest part is avoiding a hot-wallet situation.

What are "proper" fee calculations?

Are best practices specified somewhere?

Providing "truth" to a blockchain (any blockchain) from real world events is the 64 billion dollar riddle.

The problem is that all such systems rely on trust.  Who is (a) generating and (b) providing the external data to the blockchain?  There is a strong (financial) incentive to cheat and fake the data somehow, possibly even at point of origin.  At that point your cryptographically provable blockchain becomes just as fallible as any human.  It can prove that the false information was fed to it at X date and time, but that's it.

This is THE major stumbling block for all the "amazing smart contract applications" people have been buzzing about.

I would suggest to focus on that problem alone, and if you solve it, make a company out of that.

maybe your algo or something like it is game theoretically "good enough" to work for most cases.

see also:  truthcoin.  hivemind.

idea: possibly your larger system could be built on top of hivemind, or at least its truth concensus protocol.

should also include "no fee" test.

How would the developers determine the "right" amount of fee per byte?

With bitcoin likely to increase significantly over value in time, a fixed fee per byte would tend to have the effect that it becomes more and more expensive in terms of real world value to create a large block.

not sure if this is a showstopper or not.  just pointing it out.

I think everyone should have ponies and we should invent free energy and matter transmutation tomorrow and all live in peace and harmony without need for any money.

why not?  It seems just as likely as bitcoin moving to POS.

10 years?  satoshi is that you?  Getting ready to move some coins in 2019?   :-P

I think that if designing an altcoin, that could be a good way to go.

However, I highly doubt bitcoin will ever change.

I base this on:

 * changing it is a consensus level change requiring near unanimous agreement.
 * people will never agree.  Just look at the U.S. penny and nickel which cost more to produce than their face value.  But we still have them.
 * a lot of software has already been written that expects 8 decimals.
 * look how much success big blockers have had.

Controversial changes to bitcoin are nearly impossible BY DESIGN.

Well, you could, but it does not seem "correct".

Consider that a multisig transaction may have multiple signers.  As in, different people or businesses.  which is which?

The safest thing is to abort in this case, and follow up with user manually.   But you might not ever see this type of tx.

WARNING: This method can go wrong if the user sent from an exchange account or some other method that the user does not directly control, or if they sent an old-style multisig tx, or a non-standard tx.  It is NOT recommended.  But you asked.


The basic idea is to look at the first address entry of the vout structure of the first vin  of the transaction the user sent to you.
ie:  tx.vin[0].vout.addresses[0]

This is a little convoluted to obtain with stock bitcoind, because gettransactions does not include any vout.addresses field.

So we need to do it in two steps.

Step 1.

Then you will see output like this:


Notice the vout in this case is 0.  So now, let's find the matching vout for <first_vin_txid>.

Step 2.


Ok, we find the vout where "n" matches "vout" from the vin we looked at in the orig transaction.  In this case "n" and "sequence" are both 0. Therefore 1GN... is the address associated with the first input of the orig transaction.  ie, this address contributed <amount> of funds.  Note that:

1) There may be one vin or multiple vin in the orig tx.  ie, outputs from multiple tx may have been consolidated into one.  It should be relatively safe to always choose the first vin.
2) There may be multiple values in the "addresses" field, eg if type = multisig.  in this case, you should probably abort.


again, don't do this.   ;-)

If you potentially need to send refunds then the only correct way is to ask the user to provide a refund address at the time of payment.

The concept of a single guaranteed "from address" simply does not exist in bitcoin.