I want to print some crypto merch and stay within the crypto economy.

So I'm looking for a supplier of blank items that accepts crypto.  Anyone know of such?

It's ok if you are a middleman.  Eg, if you want to buy blanks for $5 from a wholesaler and sell them to me for $6 worth of BTC we can do that, so long as markup is reasonable. 

locally.   see my sig.

Thanks for the clarification.


So say the user pays 1 bitcoin when they were supposed to pay 1.00023 bitcoin.   What happens to the 1 bitcoin that they paid?   Is it at least identified as belonging to the merchant?  The merchant still receives those funds after manual processing, yes?


Why would you generate a BTC address for each impression?   Typically an address should only be generated/assigned once a user is ready to actually make payment with bitcoin, ie final stage of checkout.   I can't think there is all that much traffic at this point.

Sounds like a good starting point for a module if some of the code can be broken out.

I've done a pretty thorough review of the available open source options and am saddened to report that there doesn't seem to be anything out there that:

• provides for funds to be paid directly to the merchant
• avoids use of hot wallet  (via XPub or even pre-generated keys)
• avoids reliance on third parties, eg blockchain.info

I found gourl which has plugins for many popular shopping carts but they receive/forward and take a cut.  I haven't looked at their code yet... it may be possible to fork and replace the naughty bits.

I don't have much time just at the moment either, but I'm contemplating writing something that would meet the above requirements in the coming months.

The way I see it, there could be a single core logic library and then multiple customizations for plugging into various popular shopping carts.

fbueller, I'm already familiar with your bitwasp php lib.  If you could find some time to break out the relevant bits of your code, then perhaps that could help me get a running head start.  Even if just as an incomplete example/reference.   If not, no worries...   should be straightforward enough.

OP, could you provide clarification of these statements please?


If the funds are forwarded "within 30 minutes" then that must mean that:

1) Customer Funds are initially paid to an address controlled by GoUrl, not by me (merchant)
2) For some period of time ( even if only 1 second ) the funds are within your control, not mine.
3) The private keys for the addresses you control may be stored on your servers, or may possibly be stored offline.

I found this thread while looking for a shopping cart solution where:

1) Funds are paid directly from customer to me ( merchant )
2) It is not necessary for me to have private keys on the server.  Eg, I would pre-generate addresses or use bip32/xpub for shopping cart.

But if I understand correctly, you do not provide the solution I am looking for.   Rather, you insert yourselves into the middle so that you can take a cut, right?

How do you deal with point (3) above?   Do you keep any keys on the server?   Or if not, then exactly how are you providing unique addresses for each purchase?

And also, the funds make at least one extra hop, which entails additional mining fees and confirmation time.  yes?

that's pretty good.  Anyone else providing a similar service that accepts XPUBs and provides notifications?   For a robust solution, at least one fallback/failover is needed.

I must say, after going through most of the shopping cart interfaces linked to on the wiki, I'm rather disappointed.   It doesn't seem like there is really any activity or updates, so I guess most everyone is relying on third parties rather than running local instances.   :-(   that, or people are rolling their own private solutions with bitcoind, something I've done in the past.

Hi, I prefer to accept bitcoins for myself rather than depending on a 3rd party processor  ( even one that uses multisig ).

Of course, it is a bad idea to keep a hot wallet that generates new addresses, and also maintaining a running bitcoind or btcd instance is tiresome and adds another possible point of failure locally.  been there, done that.

So what I'm looking for are shopping cart modules for accepting bitcoin that:

  1) Can use a pre-generated address list.   ( or XPUB from HD-Wallet, even better )
         ( so that private keys are never stored on server. )

  2) Can query a blockchain APIs to determine if a payment has been made.

  3)  ideally it would use a pluggable API interface, so it could query against blockchain.info, insight, toshi, bitcoind, btcd, etc.   automatic failover would be great.

(1) and (2) are requirements.  (3) is nice-to-have.

Anyone know of such a thing?    I would hope there would be several, for different shopping carts. 

I've been looking at some of them from this page:
  https://en.bitcoin.it/wiki/Category:Shopping_Cart_Interfaces

But so far the one's I've looked at seem to be old and either the docs are too vague or they are clearly just hot wallets relying on bitcoind.

If I receive multiple responses that match the requirements I will consolidate them into a list in the OP.

I'm also interested in your experiences good/bad with the various bitcoin shopping cart plugins.

thanks.

thx for the reply.  I'm presently writing a command-line utility that performs wallet-discovery.  The idea is to read in a master xpub and then generate all of the receive and change addresses for the wallet, checking for received tx, until the gap limit is reached.  (It also handles multiple masters as in the case of copay wallets.)

In fact, I'm using your bitwasp library, so thx for that also!

As I have read bip32, bip44, and bip45 more, I have come to realize that the fault is not entirely with wallet authors using non-standard paths.  bip32 was fine by itself, but then bip44 and 45 re-defined the path in new ways causing much confusion and no way to resolve it.  So any code that is the recipient of an xpub (which contains depth but not path or bip number) is screwed because there is no in-band mechanism to know the bip-format.   Asking users is a non-starter, except for maybe asking them which wallet software and version they are using.

Even worse, if the receiving app gets it wrong, it has no real way of knowing because new (and incorrect) keys are happily generated.  They just won't have any received funds.   No way to differentiate that from an empty wallet.

Seems really broken and bad for interop and user experience.

copay is especially crazy.  Here's a snippet for how I have to deal with them.  ( Copay 1.x )



I suppose  such games might not be necessary if my app were to receive the bip39 words, but that exposes the master private key and ruins the entire idea of 3rd party audits without private keys.  And I'm not sure if that tells us the structure or not...

I am thinking we could solve this with a new bip that defines a standard format for wallet software to export master keys(s) so that necessary information is not lost, including:
  + list of xpubs  ( and/or optionally xprivs )
  + absolute path including purpose ( bip number / format identifier )
  + number of signers (in case of multisig wallets)

Basically a standard wallet interchange format.    :-)

I'm new to this hd wallet stuff.  Has anyone drafted a relevant bip already that I'm just not aware of?

answering my own question, it seems the answer is yes.  The library I am using provides a getDepth() method which seems to work for my purposes.

Still, I do not see any way to access the nodes of the path, so it's unclear if the path is formatted according to bip32, 44, or something else.  

Example, from a mycelium android xpub alone I can determine that the path is like:
m/?/?/xpub

But what I want to be certain of is:
m/44/0/xpub     ( bip 44 )

- or -

m/0/0/xpub   ( bip 32, in the wrong place )

If I'm not mistaken, the only way to obtain that info is out of band.  Eg, by asking the user "What wallet software did you export this key from?"    And then I need to maintain a matrix of wallet software versions and their idiosyncracies so I can know which bip/purpose they use for exporting keys.    fun!

Hopefully someone can inform me I'm wrong about that?   Or is there some heuristic that can be used to determine whether bip32 or bip44 is used?

Thanks for this list.  really useful to me right now.

I'm presently trying to implement a tool that can read in an XPub and then find all the addresses that have ever been used, both receive and change.  for auditing/accounting purposes.

I quickly found that a) not all HD wallets export the xpub (eg multibit) and b) wallets are exporting the XPub from non-standard paths eg mycelium.

I don't understand why it is so hard for wallet authors to simpy follow the Bip32 spec as written.  This is people's money we are talking about.  Did we learn nothing from the browser wars?   Are they doing this specifically to waste my time investigating?  sure feels like it....

ok, so to my question:    Given only an xpub and no additional info about where it came from, is it possible to determine what location it should be at in the path?     Basically my code needs to be 100% certain that it is generating the correct addresses, and also that it can find both receive and change addresses.

And for those wallets that do not allow exporting the xpub at all.... really?   seriously?   Exactly whose money do you think it is?  What alternative mechanism do you provide that enables 3rd party auditing/accounting?   oh really, none?   yeah, that's what I thought.

I'm just learning about joinmarket, so please forgive if this is a dumb suggestion, already implemented, or whatever.

I was just wondering if the weaknesses quoted below could not be overcome by something like:

1) takers provide multiple receive addresses.  say a random number between 5 and 20.
2) total output payment is divided up randomly and sent to these addresses.
3) each payment is time delayed by a random amount between 60 seconds and max secs, where the taker can define max secs.

I really like CoPay's decentralized multi-sig implementation.   Or at least the idea of it.   I am presently evaluating using it in my business to support a two step payment workflow consisting of:

1) Sally prepares a payment to Bob.
2) Jim reviews the payment and either authorizes or declines.

( This mirrors existing online banking functionality. )

In this scenario, Sally works for Jim, and Jim has ultimate responsibility for the funds.

Ok, this seems simple enough at first:  It could be a 2 of 2 or 2 of 3 wallet, for example.  ( with the 3rd key being an offline backup, held by Jim. )

But now what happens when Sally decides to leave the company and Ellen is hired to replace her?

Ideally Jim would be able to revoke Sally's key and issue a new key for Ellen.

But as far as I know, there is no provision for key revocation in bitcoin.  right?

Ok, so maybe we just ignore Sally's key and will never authorize a transaction initiated by Sally.

( and I see no technical reason why Sally could not be removed from the wallet for future transactions. )

But we still need a new key for Ellen.   And our wallet was created as a fixed 2 of 3.

So is there a way to add new participants/keys to a copay wallet?

Or more generally, I would like to know if the CoPay team has thought about this practical matter, and how they recommend for users to deal with key management when personnel change.

If I'm not mistaken, the only possibility at present is to create a new wallet for Jim and Ellen, then transfer the funds to it.   But that is gross for various reasons, not least because the transaction history gets spread across wallets.

The truncation breaks the html badly.   Real example from this site's RSS feed today:


Notice that the final tag is truncated.  What isn't immediately obvious is that the image URL itself is truncated. 

The full image URL is:

https://ip.bitcointalk.org/?u=http%3A%2F%2Fs27.postimg.org%2Fjvou3ugsj%2Fzandreas.png&t=545&c=QfibD-q76XHMGA

NOT

https://ip.bitcointalk.org/?u=http%3A%2F%2Fs27.postimg.org%2Fjvou3ugsj%2Fzandreas.png

The latter URL gives a "image proxy invalid" image.

So in this instance we have:

1) unterminated html tag/attribute

Hi 2112.  You haven't yet said a single thing that demonstrates a technical flaw in my proposal.  You also have not proposed something better or indeed anything at all.

If my proposal is "wrong" as you say, please support that statement by providing a scenario in which the outcome would not be as desired/expected by the API caller or otherwise somehow wrong/broken behavior. I doubt you can because the approach is very simple and straight-forward.  But I'm willing to consider anything concrete.  If you can point an actual flaw, then either I need to find a way to fix it, or the proposal is unworkable.  But you have not done this.

Also if you'd like to explain how the status quo is somehow better than my proposal, I'd also be mildly amused to read that justification, even though I'm sure I wouldn't agree.  Because the status quo is pretty broken with regards to fees.  It's like walking in to MoneyGram, handing them your credit card, asking them to send 10 cents for you, and please surprise me with the send fee.... the sky is the limit.  ( moneygram would probably say no to sending 10 cents, but bitcoin doesn't, so the analogy is apropriate. )

While I appreciate your contributing to the thread, I sense only negativity from you.   If you are done, that is probably just as well.

Does anyone else have comments?


Tomorrow I will consolidate the estimatesendfee addition into the original proposal for easier reading.

Hi 2112.  I appreciate your taking the time to reply in depth.

That said, it seems that whenever the subject of fee calculation via API comes up, there is a lot of negativity shooting the messenger and very little contructive effort to actually come up with a solution.   I'm hoping to see more of the latter this time around.

anyway, I will address your points.



a) How coin-selection works is an implementation detail of bitcoin core.  It is not something that API clients should need to know or care about.  Getting hit with a surprise fee that is 20%, 50%, or larger of the send amount IS something that API clients should and DO care about.

b) I do not see how this "stochastic approximation" breaks the sample application code I pasted.  You see, with my proposed modification, we can ignore what goes on under the hood with coin-selection.  When sendtoaddress is called, it works its' coin-selection black magic and determines a fee.  If that fee is higher than the max_fee it received from the API caller, then sendtoaddress returns with an "insufficient fee" error code. Otherwise it sends.  So that is simple, right?

Now, in addition to that, I proposed as a nice-to-have, an additional API calcsendfee that would take the same address and amount args as sendtoaddress.  It would call the same black magic code to select inputs and return a fee amount to the caller.  The caller could then decide whether to accept or reject that fee amount.  If it accepts it, it could then pass that fee amount as a LIMIT to sendtoaddress.  So sendtoaddress may come up with a new fee based on pseudo-randomness or input changes, and if the new fee is higher than the limit, then the send will fail.  If it is lower, then the lower fee will be used.  Everybody is happy.

Probably calcsendfee should be called estimatesendfee instead, since that is technically more accurate.

The main purpose of estimatesendfee is to provide an "order of magnitude" type of estimate to the caller, so it doesn't have to waste cycles starting with a very low limit (eg 0) and working upwards calling sendtoaddress.  This API could also be useful to determine how much fee variation is taking place from the pseudo-random behavior.


Yes indeed.  I'm well aware and my proposed API change accounts for that.  See 1b above.

Nevertheless I would not be at all surprised if in the majority of cases, the fee calculated by sendtoaddress would be the same as the one returned by estimatesendfee.  Anyway, that would be interesting to watch.


I'm not sure what you mean by "solve the first two problems".  Rather than "solve" them, I just observe that those are implementation details the caller doesn't need to know about, and can be worked around with the proposed fee limit.


yeah, that's one of the use cases this proposal is aimed at.  See original description.   If one is able to define a max fee, then one can enforce a business rule that we do not pay above 1% fees (for example) when transferring to cold-storage.   If the fee would be higher, one can then choose to wait until a later time, or retry and maybe get lucky with a new coin selection, or create a raw transaction.


I don't see that this list added anything to the discussion that I had not already considered and/or discussed already in this thread. Nevertheless I thank you for the opportunity to more fully elaborate.  I also don't think that calling it a "short-sighted temporary hack" is justified or polite.

If you have a far-sighted, non-hackish proposal in mind, please do share.


surmise whatever you wish.  I'm not here out of ego.  I just want something implemented that is useful.

I have no objection to a 2 phase commit approach.  That's what I meant by locking/state in an earlier comment.  However I think that perfection is often the enemy of the good, and right now we have neither.   I believe my proposal is at least workable and should be simple enough to implement that even someone with relatively little experience with bitcoind code like myself could do it.  While I would not trust myself to implement 2 phase commit correctly.

Again:  if you have something better in mind, please post it here.  I would very much like to see the actual API calls you propose and pseudo-code for using them. That can lead to more productive discussion.   Otherwise, it seems you prefer to just cast stones...


I'm still hoping we can get some type of consensus that either:

a) that my proposed API changes make sense and will be accepted if implemented well.   - OR -
b) a core dev will implement some type of 2 phase commit for a true calcsendfee API


This is getting off into the woods a bit.  I agree it is messy for the server to call the client.  Still I don't see what prevents something like:  lockallunspent( true );  fee = calcsendfee();  sendtoaddress( ..., fee );  localallunspent( false );    Anyway, I don't wish to debate about this, because my proposal handles it in another way without requiring locking.


I went down that route.  Unfortunately the required fees keep changing from release to release, so properly estimating them is tedious and error-prone.   Another factor for me personally (and for some others) is that my code is designed to work with altcoins as well as bitcoin, so it is much cleaner if the wallet software itself lets me know what an appropriate fee is and/or enforces a limit.

oh and also, if you look at this pseudo code again:



Notice that there is a new fee parameter to sendtoaddress(), which in this case is the value returned by calcsendfee().

That fee would act as a limit for sendtoaddress.    So if the fee that sendtoaddress generates pseudo-randomly is higher than the limit, then it would not send and would return an "insufficient fee" code.   If it is less or equal, then it would send.

So I believe that handles your objection.

You seem to be missing the point that this is a sharp pain point for developers and businesses.  And just plain bizarre that one can't know a fee until after the fact.   too bad if the fee turns out to be 20%, 50%, 100% or even more of your send amount!

Also, if you look at my original proposal in this thread, you will see I am well aware that the fee could change between API calls.  That's why I proposed an alternative with a fee_limit param for sendtoaddress.  That would work fine with the existing pseudo-random sendtoaddress implementation.

Even still, I can wish for something better.  As I said, "perfection to me would be...".

Bitcoin-qt allows the user to view the fee and either send or not.  So what technical reason prevents that capability from being exposed at the RPC API level?   Do we need to add some locking/state around calcsendfee/sendtoaddress?  fine, let's do that.

Or there could be a deterministic alternative to sendtoaddress that RPC users could use when they want a fee calculated.

I believe this is not a technical problem so much as a "la la la" we don't want to fix it cultural problem.

My concern is that if I (or anyone) go to the work to fix it and submit a patch, it won't get accepted, due to core team resistance.

Am I wrong?

My hope with this thread is that we can get some amount of concensus on an approach, so that when it gets implemented, it will be likely to be accepted.

I'm not entirely sure what good worrying about the average of fees in total is when I have zero control over it using send* apis.  In fact I am here making a proposal because I do worry about it.

The case of small amounts may actually be where this is most useful because the fees can presently eat up 50% or even 100+% of the send amount.  But its hard to KNOW that until you actually try to send.  And then you get the surprise fee amount like an unwanted toy out of a cracker jack box.   So it is often preferable to wait until those inputs have aged sufficiently and/or enough other larger inputs have come in that the overall fee percentage goes down to something like 1%. Or maybe just wait till btc price rises and those dust are worth something.  whatever.... it should be my application (or its user's) choice, not some algo within bitcoind.

In the case you mention where many dust inputs are received and it jams things up, it is still useful for the app to be able to make informed decisions.  Maybe the decision is to call lock_unspent for some utxo, or log a warning or email the site administrator.  Or maybe it is just to send again with a higher fee limit or no fee limit at all.

Right now the app developer's options are to either blindly call sendto* and take the fee it arbitrarily comes up with or else write your own coin selection and fee calculation routines and generate a raw transaction.  I've been down that route....  it is painful and error-prone, and only a few people will get it right.


I'm not saying the proposed API change is perfect... actually perfection to me would be if I could write app code something like:


There would be a corresponding calcsendmanyfee also.  sendtoaddress might (rarely) return insufficient_fee error code if conditions have changed since calcsendfee() returned.  In that case, the application should retry, possibly multiple times.

I'm guessing this approach is a bit more involved to implement than my first proposal, but maybe not too bad since it is already calc'ing the fee internally anyway.

thoughts?

Having worked on a few sites using bitcoind, a recurring pain point for me (and apparently many others) has been the inability to know the fee prior to sending.  This is particulary troublesome because the fee can vary wildly as a percentage of the send total, and business rules may preclude sending when a fee is higher than a given percentage.

It's sort of like if you walk into Western Union or Money Gram, and ask how much it will cost to send money.  They say, don't worry about it.... it's kinda complicated to figure out so just leave us your credit card and you can look at your statement later to find out how much we charged you.  They don't do that because people would not accept it.  We like to know up front, or at least be able to set limits.

Often when sending bitcoin it may be desirable to wait until the fee is less -- either because the coins have aged, or we have restructured our inputs, or we are sending a larger total resulting in a smaller percentage fee.

In other words, the fee itself can be an important factor in decision making whether to send a transaction.

I understand it may be difficult or problematic to implement a getsendfee() type of API because the fee could change, etc.

However I know that for my own use cases, it would be very helpful to be able to set a fee limit.  So that sendtoaddress or sendmany would succeed if the fee is below the limit and fail if over.

So the APIs could be:


where max-fee can be either:
a) a fixed amount, eg: 0.001
b) a percentage amount, eg: 1%

If the transaction would exceed max-fee then an error is thrown.  Applications can catch that error and optionally try again with a different combination of amount and max-fee.  At least the app knows the fee was insufficient and can act accordingly.

Use cases for this functionality

1. A merchant or other bitcoin receiving website maintains a hot wallet and regularly sweeps to cold-storage.  

   Owner wishes to wait until either:
        a) enough funds have accumulated and coins aged sufficiently to send with 0 fee.
        b) funds total passes a given threshold, and will then accept up to a 1% fee.
        c) funds total passes a higher threshold and will then accept up to a 3% fee.
        etc.

2. A mining pool or other agent needs to send to many recipients.  

   Agent wishes to wait until enough funds have accumulated and coins aged sufficiently to send with 0 fee.
   Agent will send to individuals sooner if requested, but will deduct max_fee amount from their payment to cover the send fee.


But what about floating fees and txconfirmtarget?

At first I was hoping that floating fees would remove this pain point, but it doesn't really seem like it does.  According to Gavin:


Now that sounds pretty fuzzy to me.  I don't see how I can use that capability to enforce a business rule that we don't send unless fees are below X percentage.  If it is possible, please enlighten me.



So... what do you think?    good idea or bad?    and how easy or hard to implement correctly?


I'd be glad to a crack at this and submit a patch, but only if there is some amount of consensus that it is desirable functionality and reasonably straight-forward to implement.

It's ok.   The dude abides.


Anyone have time to create a subreddit for LBW?   I think that could get us some more exposure.  maybe eventually add an LBW tip-bot, etc.  Or just have fun posting lebowski quotes, images, vids.

by definition we would be the coolest sub-reddit on reddit.  Even if we believe in nothing and lay around at the pool all day watching bunny.  

Just because of our dude-ness.

Fuck it, let's go bowling.