Fees in QR code: I've seen the notion of letting a recipient specify fees (for example in a QR code) discussed, and i sort of mentally dropped the idea because someone pointed out that it could be abused. Eg. someone sets a fee of 10BTC, and the dude spending hasn't had his caffeine for the morning yet and doesn't notice before signing the transaction. Poof, 10BTC gift to the miners. Useless for theft, but effective for inflicting damage upon unwary users.
I think a more robust solution is 2 parts:
Step 1. As Gavin has stated many times - better fee calculation in the client based on dynamic reckoning methods rather than hard coded values. In essence, recommend the smallest possible fee to the buyer that will ensure smooth processing. Because of the way the miners prioritize transactions, as I understand it, the fees could vary quite a lot - from zero on big old bitcoins to a few cents if a lot of small young tx are being merged. The client program would enter nirvana if it could have a standardized way to reckon what is fair and reliable thus over time as trust in the method grows - removing this issue from the end users worry.
Step 2. Recipient confirmation should include not only verification that a transaction in the right amount has entered the queue for processing, but also that the fee is realistic based upon how the transaction looks in reference to the above reckoning method in point 1. If I were a Point of Sales terminal developer, I would see it as very important to make sure the fee looks good before you let the customer walk out the door with the goods (so to speak), otherwise you open yourself to what amounts to shoplifting if a payment is never processed.
I know 1 is in the works now. Once 1 is in place then it will be trivial for merchants to compare if the actual fee meets the recommended network fee thus accomplishing step 2. Without point 1, then 2 is gonna kinda suck as the only way to judge if someones fee is good enough is subjective and open to argument / voodoo / personal belief.
If a fair floating fee reckoning mechanism gets implemented into the main client, it would be an incredible step forward. 1. You know, there is a risk on merchants' end of transactions not getting confirmed, if the merchants are not using a professional Bitcoin payment processor (like Bitpay). 2. The idea behind this feature request was to mitigate the risk of being paid but not receiving the funds. Sure, if this feature was to be implemented the way I proposed, another risk would be created, i.e. excessive transaction fees attached / enforced by pranky merchants. This risk could be however mitigated by a mechanism (devised by smart people like you) that would prevent sending excessive fees; e.g. Bitcoin-Qt would detect the smallest accepted fee by a pool and simply add this smallest accepted fee and generate the appropriate QR code. 3. Another idea behind this feature request would be to create a new job type (introducing agent to Bitcoin payment processors) in the Bitcoin business for people like me who are able to convince local businesses to start accepting Bitcoin payments. This could work like this: a) I create (over a certain period of time) a pool of e.g. 10 - 20 local businesses who regularly generate a turnover that Bitcoin payment processors find attractive b) then I transfer this pool to a Bitcoin payment processor c) the Bitcoin payment processor pays me a commission for a certain period of time. Why I think this job type is needed for Bitcoin? 99% about Bitcoin is and was written in English. Bitcoin needs a bridge to non-English speaking markets. This job could thrive in regional non-English speaking markets and would speed up Bitcoin adoption process. It is just my opinion. Debug window feature: Your first request was for this and I agree with the other posters that we don't want to make it easy for noobs to use the debug window as they can do silly (verging on dangerous) things over there. If it were my prerogative, I'd hide the debug interface completely with a well documented, easy, but not obvious activation method so developers can turn it on if they need it. Most users are scared by the debug window and quickly close it, and others only know enough to be dangerous. Relatively few know enough to use it fruitfully. My argument is that noobs will experiment with Debug window anyway (not with all commands)- this will be more detrimental. I think that those safer commands should be availed to users in a non-command version. Well, this is where we disagree  |
|
|
|
As I understand from this https://gist.github.com/gavinandresen/4120476What about a merchant-pays-fee feature?
It is desireable to allow a merchant to pay the cost of any Bitcoin network transaction processing fees, so if a customer is paying for a 1 BTC item they pay exactly 1 BTC.
The consensus is to change the transaction selection code used by Bitcoin miners so that dependent transactions are considered as a group. Merchants or payment services with one or more unconfirmed zero-fee transaction from customers will periodically create a pay-to-self transaction with a large enough fee to get the transactions into a block. the idea is that the merchant would cover transaction fees. I think this could be a solution. I do not necessarily like it, but this feature in the system would be helpful. Thanks for the links. |
|
|
|
Maybe take a look into the suggested payment standard from gavin iirc.
Gavin Andresen? Where should I look for the info? |
|
|
|
Let's see if the support line holds at around $117.
Might fall deeper. Looks a double top to me.  |
|
|
|
This is what I want  |
|
|
|
I recently spoke to a few businesses in my region. The owners (1 cinema and 2 restaurants) want to run a trial that will look like this: 1. I am sitting home. 2. Businesses send me an e-mail with the bill amount, e.g. $3 or $25. 3. I generate the QR code (on my Bitcoin-Qt) for the amount on the bill (using the current rate of exchange at MtGox) and send the QR code to the business. 4. A customer scans the QR Code and pays in Bitcoins ( the customer must include a transaction fee so that the transaction is confirmed quickly - this is what this feature request is all about). 5. I (i) either keep the Bitcoins for myself or (ii) sell them on MtGox. 6. The next day or the same day I put cash (in national currency) into the businesses cash registers. 7. If the trial / experiment is successful, these businesses will look for a professional Bitcoin payment processor. |
|
|
|
Let's say the IRS wants to be able to confiscate bitcoins from tax evaders. So they go to the US courts to get this. A judge ends up ordering the bitcoin.org dev team to include a government backdoor so the IRS can take funds away from those who don't pay taxes.
The devs would be forced to comply right?
Would the judge pay the devs for the backdoor programming from his own pocket? |
|
|
|
You could simply print out a QR code requesting X BTC (X being the ticket price) Is there a way to print the QR Code (using e.g. Bitcoin-Qt with: a) price to be paid by the buyer - this is standard ANDb) transaction fee to be enforced upon the buyer? The reason for b) is that I want to mitigate the risk of the buyer not attaching the fee and therefore the transaction going into limbo or staying unconfirmed for a long time. Thanks |
|
|
|
BitcoinWisdom, I would love your website to avail trendline drawing. But still your website rocks  |
|
|
|
Fantastic website. Learned about today I like to have the charts clean (only candles + volume indicator below). How do I get rid of MACD and those three lines on the volume indicator? |
|
|
|
I have 2 weeks of exams coming up followed by a family holiday, so I won't be able to put in too much effort. Enjoy your family holiday |
|
|
|
There are a couple of solutions I've already thought of, each with pros/cons, so I think it should be resolved soon.
Can you share your thoughts on possible solutions or is it too early? |
|
|
|
|
What promotional materials do you suggest: stickers, posters, others? Where can we get the design / Bitcoin logo from?
|
|
|
|
You could simply print out a QR code requesting X BTC (X being the ticket price)
People with bitcoin scan using their phones, then hit send. You could have a PC running the client with Bitcoin-Qt open. It would post the transaction in under 3 seconds and then they could be given the paper ticket even with 0 confirms(The chance of an invalid transaction is currently 1/10,000). By the time the movie is over, you'd have the spendable bitcoin in your wallet.
Sell the coins on localbitcoin.com if you want the local currency.
The people working in this cinema are artistic souls who have problems using a computer. It looks like I will do the charitable work and: a) will sit there for a month with my laptop b) will generate QR codes using Bitcoin-Qt based on BTCPLN rate of exchange on MtGox, and then c) after receiving payment in Bitcoin, I will be putting Polish currency into the cinema cash register untill a better option is found EDIT: There is a free WiFi in the cinema. Maybe WiFi could be used somehow to facilitate Bitcoin payments. |
|
|
|
If there's enough push for shorter timeframe scaling, I'll add 1 and 10 minute frames as well.
Good |
|
|
|
After talking with Jordan Tigani from Google's bigquery project, it seems that this tool may stop working at some point after MtGox starts regular updates, because Google occasionally performs coalesce operations that don't respect the order of rows in a table. I read your discussion with Jordan Tigani (I do not understand it very well) Coalesce happens on the order of once every 300 times you append data to the table. The database is being maintained by a financial company, and they plan to start updating it automatically (up to every 10mins). and have one comment: if the acceleration rate of number of transaction (ticks) is maintained (you know, more people will perform transactions more frequently) one can expect that in a few years 300 appendices will be made within one second. A year ago millisecond timestamping was a standard for reporting ticks. At the moment microsecond timestamping (one millionth of a second) is being introduced by financial data vendors and exchanges. I do not think 10 mins update is sustainable in the long run. Otherwise it will end up costing around $60/month to keep local copies regularly updated because `order by` queries will need to be run for each update instead of a simple (and free) tabledata:list. Running SQL queries would also slow down the tool speed. Is $60/month the cost to be incurred by MtGox / you or by every single user of this service? If bigquery doesn't implement some kind of row order permanence, then I'll ask MagicalTux to consider doing this officially. Couldn't MtGox just invest in servers / rent a data centre and pay a programmer like you to make a dedicated service / tailor made service instead of spending many hours talking to Google (without a guarantee for a success) - time is money. Then MtGox can simply provide data API service to customers who will pay e.g. BTC 0.5 per month - it is a standard practice in financial industry that data API is provided to users (i) for a fee or (ii) in exchange for maintaining a certain balance in the account (e.g. if you want API from Dukascopy forex broker you must have a balance of at least $100k) |
|
|
|
|
Hello,
I have a friend who owns a 80 seat movie theatre in Poland. I convinced him to start accepting Bitcoin. Tickets are sold at price USD 2 - 6 (depending whether you are a child or a student or a senior or the movie is 2D or 3D). There are 10 different ticket prices. Ticket prices change once in a year, so no very often.
I have a couple of questions.
1. Which Bitcoin payment processor do you recommend and why?
2. How often does the Bitcoin payment processor send the money in a national currency to the merchant (every day / every weak / month / quarter)?
3. What infrastructure do you recommend for a movie theatre (dedicated android phone, dedicated laptop or a desktop, others)?
4. What happens if only 1 ticket worth of USD 3 is sold during a year? - wouldn't banking fees for sending this money to the merchant wipe out the whole income?
5. What else should I ask?
Thanks.
|
|
|
|
Current Analytical Functions:
1. Simple Moving Average
2. Exponential Moving Average
3. Moving Average Convergence-Divergence
4. Relative Strength Index
5. Support/Resistance
6. Aroon Oscillator
7. Stochastic Momentum Index
8. Chaikin Volatility
9. Bollinger Bands
10. On-Balance Volume
11. Linear Regression Trend Lines No Volume? There's plenty of on-chart drawing ability. Including trendlines? As is, the charts only scale down to a 30 minute timeframe. I don't think I'll be making them any finer resolution than that. It is a pity. Add at least 1 and 10 minute timeframe. |
|
|
|
It will have normal and automated trading capabilities in addition to advanced charting/analysis tools [...] I was just wondering what sorts of end-user analysis functionality people would want to see in a service like this. 1. Ability to draw trendlines on a chart. No web service allows users to draw trendlines  2. Multiple time frames, at least these ones: 1s, 10s, 20s, 30s, 1m, 2m, 3m, 5m, 10m, 15m, 20m, 30m, 45m, 1h, 2h, 3h, 4h, 6h, 8h, 12h, 18h, 1d, 1w, 1q |
|
|
|
|
Show Posts
