I am just curious to know why Bitcoin developers choose a complicated approach like UTXO, rather than using the transaction models used by Ethereum Blockchain.
Basically, Bitcoin nodes maintain a set of all active UTXOs which have not been spent yet and any transaction that comes in is validated using this set. The nodes also update the UTXO set after every transaction.
This model is very analogous to how you'd implement a "wallet" which held currency notes and coins albeit with perfect traceability of each note in your wallet as to where you received it from! It is not complicated once you understand this basic analogy.
Consider the case where you have only a 20$ bill in your wallet. Let's say you buy a product worth 6$ with this 20$ bill. In this case, you will get BACK 14 $ in "change" and these notes are akin to the "unspent transaction outputs". These notes (UTXOs) can then be spent in any later transaction.
The advantage that UTXOs have is that each UTXO can be traced back right upto the point where the actual bitcoin was created (miner reward for example) and even upto the genesis block potentially.
This is akin to your being able to trace back the 20$ bill from where/whom you received it, and in succession being able to trace back how that person received this 20$ bill and so on and so forth until you traced it back to the Federal Reserve Bank mint where it was printed!
You can imagine how this would dramatically increase the security and trust in the system because you could validate each and every facet of a transaction.
However, this model was considered as not efficient enough for the Ethereum protocol which also has smart contract transactions which might execute frequently. Due to this, Ethereum went for a "Account state" based model which makes it far more efficient to calculate balances before and after transactions.
Here are some helpful links that might answer your question:
Considered as skewed towards a pro-ethereum viewpoint - https://ethereum.stackexchange.com/questions/326/what-are-the-pros-and-cons-of-ethereum-balances-vs-utxos
Also a Medium article which goes into more detailed comparison on the UTXO and Ethereum Account State model https://medium.com/#sunflora98/utxo-vs-account-balance-model-5e6470f4e0cf
Related
I am trying to display a users transaction history in binance, including fund deposits and withdrawals as well as buying and selling of different crypto's. Does anyone know which binance API endpoints I would use to do this? It seems quite complicated in comparison to other trading platforms.
Thanks
This is the link to the docs: https://binance-docs.github.io/apidocs/spot/en/#withdraw-history-supporting-network-user_data
I can see the Wallet endpoints "Withdraw" and "Deposit", but this won't cover crypto trading will it?, The account trade list call would be ideal, but it requires a symbol input which I'm not sure how I would obtain dynamically.
I would also like this endpoint to provide me with the data so I can get the avg buy price for a crypto
Currently this is not supported. See: https://dev.binance.vision/t/fetch-all-account-orders/279/3
This is the route you're looking for to get the user trade history. The big downside is that you have to specify the exchange symbol, you cannot get the history of the account with just one request:
https://binance-docs.github.io/apidocs/spot/en/#account-trade-list-user_data
Get your account information first. You can then extract non-zero balances from here to get symbols for transactions. You can then loop through each currency pair and get its transaction history. This seems to be the most optimistic way we can get right now
You can also try to use caching. For example, you can remember balance for a particular coin, and if it has not changed by the next launch, then it is likely (but not 100%) that no transactions were made with it
You can also connect to WebSocket, but this is still a terrible crutch and requires a DOS attack to get the necessary data
Please note that here the balances for Savings wallet have LD prefix added to their ticker. For example, BTC in the Savings wallet is labeled as LDBTC
TL;DR: If you use BAPI_GOODSMVT_CREATE to create multiple co-dependent movements and one of them is a transfer posting, then you need to use a wrapper - per SAP note 369518. If there's no transfer posting somewhere, a COMMIT is enough
Has anyone looked into the specifics of Note 369518?
It describes a requirement to start a new roll area before calling BAPI_GOODSMVT_CREATE for a goods receipt that depends on a previous goods movement (posted also by the BAPI within the same LUW).
What is unclear to me: Does it apply to goods receipts in general? Or somehow only to goods receipts that involve an "implicit" (sic) GI for stock in transfer?
I am looking for a technical walkthrough of the section "Reason and Prerequisites".
I need to decide if for a sequence of movements 262,102,101,261 on the same batch, the BAPI should be called in a new roll area each time. For this, the user will need to be asked to close a window if they have the maximum internal sessions already open. (Edit: The part in italics may not apply as I believe that DESTINATION 'NONE' will start a new user session)
Best I can tell, the answer hinges on the note's "machine translation" into English: Google offers the alternative phrasing "only with a real outgoing goods, inventory is read from the database", which clears it up a bit:
The BAPI looks into the buffer always, regardless of which movement type it is tasked to create. The issue is that a transfer posting (A08 in MIGO) does not update the buffer. While a "real outgoing" goods issue (A07 in MIGO) does, allowing the subsequent goods receipt to correctly detect the stock.
So only if a prerequisite movement is a transfer posting, is it necessary to start the dependent call in a new roll area.
I'm currently evaluating using Plaid or Yodlee for transaction aggregation (I'm using the Dev environments for both right now). I really prefer almost everything about Plaid, but I'm having trouble with transaction name/description. Yodlee has a data field called the "simple description":
From their docs: "The transaction description that appears at the FI site may not be self-explanatory, i.e., the source, purpose of the transaction may not be evident. Yodlee attempts to simplify and make the transaction meaningful to the consumer, and this simplified transaction description is provided in the simple description field."
I'm displaying the transaction name to my end-users and I'm looking for something more user friendly than the transaction name field which often returns strings like "Withdrawal Check Card MOE'S BROADWAY BAGE BOULDER CO Date 01/06/19 0 9006020339 0 5812 Card [XXXX]".
I'm sure I'm not the first plaid customer to have this need. How do Plaid reliant apps solve this problem?
Plaid doesn't offer a simple description field as far as I know, but they do clean up transaction names.
I've found that when a new pending transaction comes in, the name is messy like you mention (e.g. UBER *TRIP 5VVB2). But once the transaction is confirmed, Plaid normalizes it for common merchants (e.g. Uber). I don't know why Plaid doesn't offer this normalization for pending transactions, but I have brought it up with them before. Perhaps this is something that could change in the future?
A solution, albeit complicated, is to build a custom model that normalizes transaction names. That's what we are doing at Pluto Money to supplement Plaid's transaction data.
I received a direct response by email from Plaid Support:
Thanks for reaching out to us here on Plaid Support, I'm sorry about
our delay.
Our name field for each transaction represents our best effort to
balance detailed transaction information while providing a clean and
consistent API response. This behavior does vary across banks, both
due to bank behavior and our own integration quality. Generally at
larger banks our integrations do a better job at returning clean
transaction names with appropriate transaction detail but for some of
our smaller banks transaction names may be more "raw".
If you never want additional detail beyond the merchant/transaction
name in your app I would encourage you to implement some filtering on
Plaid's name field to make sure that no date- or account number-like
character strings pass through into your user facing stream.
I am making changes to my companies internal paysite in order to come into compliance with the new credit card regulations. We have decided that when we get a split tender transaction that comes through we want to get the remaining balance along with how much was on the card to start out with and send that info back to the customer service rep with a message relaying the need for another payment source along with the remaining balance and the amount that was originally on the card.
Instead of chaining the transactions together with the split tender Id we have decided we would like to finalize each split tender transaction with a prior_auth_capture and then request the next payment source and amount and process that transaction in the same manner. I know that we are side stepping the functionality some but those are my orders.
My questions are, is this feasible and possible and how do you do this in code? I am using the C# SDK to implement this in VB.NET 2008
My thoughts are that I would have to process the transaction for the amount passed as a auth_capture transaction and then some how do the prior_auth_transaction with a zero amount or something?
How would this work?
Thanks for much for your help.
James
This is not feasible to do. The purpose of split tender payments is to logically group together split payments into one transaction. By breaking it up into multiple transactions it can get confusing for you, the users, and the processor. Especially if you have issues getting the user to make full payment on their transaction. Failing to void the other transactions would be very problematic. This almost certainly will result in an increased exposure to chargebacks.
Let us assume that there are three parties. Organization X, which provides a SaaS, organization Y, which is using the X's service, and Consumer Z which is using X's service to make purchase from Y. This is similar to something like EBay for instance in a way. Now I would like to have Y and Z directly transfer money between them while also transfering funds between X and Z. The example would be X charges and covenience fee of some sort to Z and Y actually charges for the service.
We are currently using website payments pro, but I would prefer not to have every single 3rd party (Y corporation) to need to use it. Does anyone have any ideas?
The reason this would be done is to handle liability issues more directly.
I would actually recommend against doing what you're suggesting. In effect, you want to broker a deal between two parties, acting as the channel. This is similar to Amazon's affiliate program, I believe. Is this a correct description?
First off, if you're trying to bring liability issues closer to you, you should probably plan on being a big organization. I say this because you will need plenty of attorneys, and a serious anti-fraud department. It's a lot of overhead -- Paypal spends a ton on this kind of thing. Are you sure your company can handle that kind of responsibility? After all, if doing anti-fraud isn't your core competency, it's a difficult and dangerous field to dabble in...
It's not a good idea to allow customers to transfer money between each other. They trust you, but you should not assume that they can trust each other (WRT bank account information, the only way I can think of to directly transfer money between them). Plus, it might take too long for the money to clear.
I would recommend that your company (Org X) accept the credit information from Z. Then on a monthly / by request basis, you pay Company Y. You can take your fees directly from the info from Z; you can "handle liability issues more directly", and it's a pattern that's been done before (amazon affiliates, ebay, etc.) Also, it fits it more with the structure of the payment industry, rather than trying to force a new model (X->Z transaction combined with Y->Z transaction is just a little odd).