I have a few bitcoin addresses (and private keys) with small amounts on them (0.001 to 0.01 BTC). Obviously sending them one by one to exchange does not worth their value due to high transaction fee.
Is there a way to aggregate them all into a single address to exchange the total amount then
You don't need an exchange to perform bitcoin to bitcoin transactions. You can send the all small amounts to one bitcoin address using any wallet, and the only fee you are facing will be the miner's fee, which is in your control. You can set a very small fee, or no fee at all - that will simply move your transactions to a lower priority. Wait a few days, and they will be confirmed.
If you want to do it using code, check https://github.com/primal100/pybitcointools
Related
I am trying to calculate stock market liquidity by using the effective spread, quoted spread and price impact. one of the variables that I need is seller and buyer initiated trades. How am I able to extract that information from Bloomberg ?
I want to create data prep script that pulls live data from the blokchcain (possibly using a centralized cache or API like etherscan). I'm wondering what is easy way to scrape all this data from blockchain in Python? I need the following columns for my fraud detection model.
Here is a description of the rows in the dataset:
Address: The address of the ethereum account
FLAG: Whether the transaction is fraud or not (This is our "target" column) Avg min between sent tnx: Average time between sent transactions for account in minutes
Avgminbetweenreceivedtnx: Average time between received transactions for account in minutes
TimeDiffbetweenfirstand_last(Mins): Time difference between the first and last transaction
Sent_tnx: Total number of sent normal transactions
Received_tnx: Total number of received normal transactions
NumberofCreated_Contracts: Total Number of created contract transactions
UniqueReceivedFrom_Addresses: Total Unique addresses from which account received transactions
UniqueSentTo_Addresses20: Total Unique addresses from which account sent transactions
MinValueReceived: Minimum value in Ether ever received
MaxValueReceived: Maximum value in Ether ever received
AvgValueReceived: Average value in Ether ever received
MinValSent: Minimum value of Ether ever sent
MaxValSent: Maximum value of Ether ever sent
AvgValSent: Average value of Ether ever sent
MinValueSentToContract: Minimum value of Ether sent to a contract
ERC20MostRecTokenType: Most received token for account via ERC20 transactions
The dataset comes from this link: https://www.kaggle.com/vagifa/ethereum-frauddetection-dataset/version/1
Let us assume there is a situation when I have an invoice from a supplier to my company (e.g. 1000 EUR). My company returns all the goods because of a problem. The supplier shall issue a credit invoice in amount of 1000 EUR, which I register in my system. As a result I will have (on behalf of the supplier) an account payable of 1000 EUR and an account receivable in the same amount. What is the preferred way of handling this situation, because there will be no money transferred, either way.
Should I generate a paymentApplication to both invoices? I want to see them as +1000 -1000 = 0 EUR.
The current data model and services do not support applying an invoice to an invoice, i.e. canceling part or all of one invoice with another. That is something I have considered but IMO is messy... even if it is a common practice in certain parts of the world (from my limited knowledge of it an archaic practice that isn't so commonly used any more). That could be supported though, I have certainly considered it (adding an entity or perhaps modifying PaymentApplication to support it, adding a service to do it and a corresponding GL posting service to balance AP/AR accounts).
Right now the best thing to do a cancel the original invoice, which does the proper reverse GL postings if the invoice has already been posted.
If you want both invoices in the system and canceling entries somewhere the currently supported approach is to use a FinancialAccount, basically use FinancialAccount payments to pay both invoices and then the balance of the FinancialAccount represents the amount due or owed to the external party. There is full support for these sorts of FinancialAccount transactions, doing payments both ways (withdrawals and deposits), representing the liability for positive balances in the GL, etc.
I am new to hyperledger and online payment.
One scenario I have in mind is: if A is an online shop, B is a consumer. B orders an item from A's shop and pays with Bitcoin/hyperledger. A ships the item to B once the payment is received.
With hyperledger, the process goes:
B sends A the payment via blockchain;
A is able to query how much money A owns;
But the question is:
How does A know if the transaction was from B?
How does A know how much money was sent by B?
How does A know if the transaction from B is for the specific ordered item?
Thanks,
What you'd usually do in Bitcoin is to create a new payment address that is bound to the specific order. The invoice would include that address with instructions to send the specified amount to that address and the recipient could simply wait for an incoming transaction with an output destined for that address.
At this point you'd know which customer has paid for which order, to check the amount just check the output value field in the transaction and compare it to the invoice.
I have an answer about how Paypal calculates the fees to apply to each receiver in case of a chained or parallel payment done with the Adaptive Payment API.
Is the fee calculated on the total amount payed by the sender? In this case each receiver would pay a proportional portion of the total fee. Or is it charged a fee to each amount in which the transaction is split? We will work with Spanish fees (3.4% + 0.35 euros) and in this last case Paypal charges would be significantly higher because of the fixed 0.35 euros that would be charged to each transaction. We are mainly worried about the case this also applies to the commission for the marketplace because we would be loosing money in some transactions when our commission would be lower than 0.35 euros.
This is the only info I've found and I still didn't understand it.
In the text they do not specify that issue (unless I am misunderstanding anything due to I am Spanish-speaking), so I had tried to deduce it with the examples at the end of the text although they pointed that "The scenario above is an example only and is not representative of actual PayPal fees".
But it resulted that the scenarios were completely unreal as they charged a higher fee to a secondary receiver that was receiving an amount of $130 than other receiving $150. So it was impossible for me to get any conclusion.
If the receivers pay the fee, you can specify whether the primary receiver in a payment with several receivers pays the entire fee or all receivers pay a portion of the fee.
•Sender pays the fee – the sender can pay a fee for a simple payment, parallel payment or chained payment.
•Receiver Pays the Fee in a Parallel Payment – the sender can send a payment that is split directly among 2 to 6 receivers. Each receiver pays a portion of the fee based on the amount of the payment each receiver gets.
•Each Receiver Pays the Fee in a Chained Payment – the sender can send a payment that is indirectly split among one or more receivers. The primary receiver, identified as the merchant, pays a fee and each of the other receivers also pay a fee based on the payment amount each receives.
•Primary Receiver Pays the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. If the primary receiver pays the fee in a chained payment, other receivers pay no fees. The fees paid by the primary receiver are based on the total fees assigned to all receivers.
•Secondary Receivers Pay the Fee in a Chained Payment - the sender can send a payment that is indirectly split among one or more receivers. The primary receiver doesn’t have to pay the fees with the secondary receivers paying all the fees.
Fees are determined by PayPal and are based on criteria, such as the transaction volume of the receiver.
So each of your receivers would be charged the (3.4% + 0.35 euros) if you split the payment between the receivers.