I understand the mining process in Bitcoin, but my confusion is, Did every block verified mean a new bitcoin has been discovered? and if yes did the miner become the owner of this new bitcoin. Also what happened when all coins discovered, did the chain will stop?
You don't understand the mining processing.
First question : Every block verified mean NOT a new bitcoin has been discovered.
Bitcoin mining is making computers do complex math problems to help run the Bitcoin network, and miners are paid with bitcoin for contributing. Bitcoin mining itself is the process of adding new bitcoin transactions to the blockchain – the public ledger of all bitcoin transactions. A new block of bitcoin transactions is added to blockchain every 10 minutes and has been since bitcoin was created in 2009 by Satoshi Nakamoto. Whenever a new block is added to the blockchain, the bitcoin miner who successfully added the block is awarded newly generated bitcoins AND all the mining fees from people who sent a bitcoin transaction during that 10 minutes. Right now a new block rewards 25 new bitcoins, which is a ton of money.
https://bitcoindaily.org/bitcoin-guides/what-is-bitcoin-mining/
Second question :
What happens when all the bitcoins are mined?
The bitcoin inflation rate steadily trends downwards. At the time of writing, more than 3 out of every 4 bitcoins that will ever exist has already been mined, and the annual inflation rate is just 4%. The block reward given to miners is made up of newly-created bitcoins plus transaction fees. As inflation goes to zero miners will obtain an income only from transaction fees which will provide an incentive to keep mining to make transactions irreversible.
Due to deep technical reasons, block space is a scarce commodity, getting a transaction mined can be seen as purchasing a portion of it. By analogy, on average every 10 minutes a fixed amount of land is created and no more, people wanting to make transactions bid for parcels of this land. The sale of this land is what supports the miners even in a zero-inflation regime. The price of this land is set by demand for transactions (because the supply is fixed and known) and the mining difficulty readjusts around this to keep the average interval at 10 minutes.
https://en.bitcoin.it/wiki/Controlled_supply#What_happens_when_all_the_bitcoins_are_mined.3F
Related
In our app implemented multiple plans, every plan provides more o less functionality for our clients, depending on that the price of the different plan is different.
Our plans implementation based on the RecurringApplicationCharge Shopify feature
We know that Shop owners are charged immediately upon accepting an application charge. Hence the question what happening:
if shop owner change plan from a less expensive charge to a more expensive charge
if shop owner downgrade plan by moving from a more expensive charge to a less expensive charge
?
I found billing FAQ for the shop owners, where written:
If you upgrade or downgrade your subscription with an app, then the app will prompt you to agree to a new recurring app charge. This is because Shopify allows each app only one recurring app charge to be enabled at a time. The existing recurring application charge will be canceled and replaced by the new charge.
When you upgrade your plan by moving from a less expensive charge to a more expensive charge, the charge is prorated based on the difference in price and the number of days remaining in the billing cycle. For example, if you begin a 30-day billing cycle on a $5.00 plan, and then upgrade to a $15.00 plan on day 15 of the billing cycle, you'd be charged $5.00 + ($15.00 - $5.00) * (15/30) = $10.00 USD.
do these rules work for the RecurringApplicationCharge? Or here talking about the GraphQL subscription model?
If shop owner change plan from a less expensive charge to a more expensive charge
As mentioned in the example provided by Shopify a new recurring charge would be created and the merchant needs those charges to be accepted for the charge to happen. You need to manage your code logic so as to if a merchant chooses to upgrade a new charge will be made and the pro rated amount will be charged to the merchant.
If shop owner downgrade plan by moving from a more expensive charge to a less expensive charge
There won't be any refund in this case. You would however need to create a new Recurring charge which the merchant will be charged in the upcoming billing cycle. The merchant needs to accept the new recurring charge.
Do these rules work for the RecurringApplicationCharge? Or here talking about the GraphQL subscription model?
Both do the same thing
I want to add some unit tests for our billing system which is using braintree but I don't know how to change the subscription period from 1 month (minimum in braintree for now) to 1 day. I cannot wait 1 month to execute my test. is there any solution to do that?
I recently asked Braintree support a similar question and here is the advice I was given:-
The sandbox environment is setup to mimic the production environment exactly. Unfortunately, this leaves us at the mercy of real time as well. However you can definitely test the subscription_charged_unsuccessfully and subscription_went_past_due webhooks in the sandbox by creating a past due subscription using the steps below:
Create a plan with a 1 day trial and $2000 price (a test amount that will automatically simulate a decline)
Create a customer with a credit card
Create a new subscription using the plan and customer
The first charge attempt will be after 1 day (when the trial expires) and will fail
The automatic retries will be at +10 and +20 days of the subscription going past due – this timeline can be changed by updating the recurring billing retry logic in your Control Panel
You could also test the subscription_charged_successfully webhook using the same basic principles – simply create a plan with a 1 day trial and a price less than $2000.
I hope that helps.
I work at Braintree. Feel free to reach out to support#braintreepayments.com with any further questions.
You can't modify the subscription billing period to shorter then a month. Sandbox is designed to mimic production for end-to-end testing and since Braintree doesn't offer subscription billing in smaller increments then a month we have decided to not offer a shorter billing period in sandbox.
I just wanted to ask among the gurus here if anyone has ever attempted to test a complete transaction from start to end on an ecommerce site using paypal or any other epayment gateway.
Please guys, I would appreciate any thoughts and comments. As it is a live site, I cant use the sandbox as that will negatively impact sales. However my firm is a startup and so can't afford the complete transaction and refund process that was suggested [here]:Accepting dummy credit cards on a live site with ActiveMerchant & PayPal.
Please help!
Previously I tested by buying low cost items from myself - that way you're only paying commission and you're getting most of the moneyback.
Admittedly you need 2 Paypal accounts, but that shouldn't be a problem, and you should only have to 'kick the tyres' in the live environment because all your testing will have been done in the dev environment.
We had a similar problem during startup and still use this process in the live site. We have specific "test" products that we purchase using a live credit card, then monitor the transactions: purchase, decline purchase, subscription (recurring billing), cancel, refund, etc.
Our test product is priced very low (5 cents). For subscriptions, the billing interval is 1 day, for a maximum of 3 intervals (with a free trial period of 1 day). This allows me to run a full test/validation, including recurring billing, in the live environment in less than a week.
We refund all charges following the test, which puts the money back on the credit card (or back in the PayPal account). Because of the refunding, our sales impact is zero (offsetting sale and refund). It does cost us a small non-refundable PayPal fee for each transaction, but that amounts to $1 or less.
These "test" products are not exposed to normal users. Also, we manually verify any "test" sales to make sure they are part of our internal testing.
"Sandbox" testing is the way to go during development, but a periodic test in the live environment is necessary to be verify that nothing is amiss.
Why not use a real credit card, then give yourself a refund? The commision fee is returned in that case.
All the time that I want to test our live sites we use a real credit card.
Thanks
I don't understand why you can't use the sandbox..?? How would using it negatively impact your sales? It's all fake.
Just setup your own sandbox.yourdomain.com version of your site and use that as your test server. Configure it to use PayPal's sandbox with sandbox API credentials, etc. This will allow you to go all the way through an order process and test everything from the UI stuff to payment processing, API requests/response processing, IPN, etc.
When everything is working you sync it up with your live server, which is hitting the live PayPal server, of course.
Again, I don't see how that would impact you in any way other than being a successful testing solution..??
I'm looking at the possibility of setting up limited acceptance of debit cards online. However, as I research, I see that there are huge differences in the interchange rate between debit cards that are regulated under the recent Durbin amendment and those that are exempt. Depending on my merchant account fee structure, this could give us wildly different costs based on how the transaction gets categorized.
If I'm using authorize.net as the gateway, is it possible to use their API to determine the categorization of the card on the interchange with just an authorize transaction? (and thus accept only cards that I know can be processed cheaply, and give an "i'm sorry" message to everyone else). Is there any other way to identify them without actually making the charge on the card?
Unfortunately there isn't. The rates used to process a transaction are determined at transaction time and are not available via any API. You can only find out what rate was charged by viewing the reporting offered by the merchant account provider.
I'm using MKStoreKit, and it features a rather useful method to restore purchases, as explained here
However, I use consumable currency to unlock objects. Each object that is unlocked by spending currency is only unlocked locally, so if the user spends 1 currency to unlock 1 object, then deletes and reinstalls the app, that 1 object won't be remembered as being unlocked.
One way around this that doesn't involve storing user details on my own server, would be to create non-consumable in-app purchases for each object, and unlock them when the user spends the currency. Thus the non-consumable is invisible to the user. I haven't tried this and it's not ideal, since there's more overhead in adding purchases, but I can't see why it wouldn't work?
Which leaves the currency. Can I restore the currency using MKStoreKit without having to log it on my own server or taking user details via GameKit etc? Many thanks!
About your first question, the only real difference in the user experience if you did it with separate non-consumables would be that they would be asked to complete the transaction when you ask store kit to buy the non-consumable rather than when they buy your currency. This makes the concept of currency somewhat irrelevant, since in the model you describe, they are charged only when they spend, and it's proportional to how much they spend.
If you already have a released app, with real people who have paid for this currency, you're going to have to support a transition period where those who have tokens left can spend them and avoid calling store kit in those cases since it was already called to get the tokens. Also make sure you stop selling new ones.
If it's a new app, just ditch the idea of currency entirely and support buying things with real money. That's what it looks like to the user and that's what it really is, now.