Bitcoin Forum
April 27, 2024, 12:00:08 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Alternate cryptocurrencies / Altcoin Discussion / Re: Will crypto really go to zero? on: October 10, 2019, 12:50:04 PM
And again, Vitalik never said anything near that.
The question "Will crypto really go to zero?" is purely from the imagination of the OP.  Grin
2  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 02, 2019, 05:27:33 PM
Quote from: reardenlife
Or it is just easier to re-broadcast every hour?  Grin
This is unnecessary, nodes will keep it as long as stated in their "mempoolexpiry", 336 (336hrs/14days) default.

Alright. I see.  So it should mean that the transactions should never get dropped from the mempool in practice.

Yet the users like KittenBob trying to convince me that the transactions are dropping from the mempool all the time.  I am still trying to figure out when and why though.
3  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 02, 2019, 05:20:08 PM
What you need to do is don't set the TXs with RBF and set mempoolreplacement=0 for you to reject tx with double spent UTXO.
But some nodes will still accept replacement tx with mempoolreplacement=1 which is enabled by default.

I've got a better idea.  Here is the main code of my mempool explorer:


Code:
# Get hashes of transactions in the mempool
#
sql="START TRANSACTION;"
Tx=$(bitcoin-cli -rpccookiefile=$cookie getrawmempool | jq -r .[])
sql=${sql}$(echo "$Tx" | sed -e "s/^/INSERT IGNORE INTO exp_mempool(hash) VALUES('/" | sed -e "s/$/');/");
sql="${sql}COMMIT;"

mysql -h"$mysql_host" -u"$mysql_user" -p"$mysql_password" "$mysql_db" -BNs <<-EOF
  $sql
EOF

# Cleanup
#
mysql -h"$mysql_host" -u"$mysql_user" -p"$mysql_password" "$mysql_db" -BNs <<-EOF
  DELETE FROM exp_mempool WHERE tstamp < NOW() - INTERVAL 3 HOUR;
  DELETE FROM exp_mempool_tx WHERE tstamp < NOW() - INTERVAL 3 HOUR;
EOF

# Select only unprocessed transactions
#
Tx=$(mysql -h"$mysql_host" -u"$mysql_user" -p"$mysql_password" "$mysql_db" -BNs <<-EOF
  SELECT hash FROM exp_mempool WHERE is_processed = FALSE ORDER BY tstamp ASC LIMIT 500;
EOF
)

# Process mempool transactions (populate exp_mempool_tx table)
#
_header "$(date --rfc-3339=seconds)"
sql="START TRANSACTION;"
IFS=$'\n'
aTx=($(echo "$Tx"))
nTx=$(echo "$Tx" | wc -l)
echo "transactions:$nTx"
if (( $nTx == 0 )); then
  exit 2
fi

tsstart=$(date +%s%N | cut -b1-13)
i=0
for txhash in $Tx; do
  if (( $(($i%100==42)) )); then
    tsnow=$(date +%s%N | cut -b1-13)
    opsec=$(echo "scale=2;$i/(($tsnow-$tsstart)/1000)" | bc)
    p=$(echo "$i*100/$nTx" | bc)
    printf "$p%% ($opsec tx/sec)\r"
  fi

set +e
  txjson=$(bitcoin-cli -rpccookiefile=$cookie getrawtransaction $txhash 1 $bhash 2>/dev/null)
  if (( $? != 0 )); then
set -e
    # Gone from the mempool already?
    #
    #echo "Deleting tx:$txhash"
    sql=${sql}"DELETE FROM exp_mempool WHERE hash = '$txhash' LIMIT 1;"$'\n'
    i=$((i+1))
    continue
  fi
set -e

  # Make sure the transaction doesn't support RBF
  #
  rbf=$(echo "$txjson" | jq -r '.vin[] | select(.sequence < 4294967294)' | wc -l)
  if (( $rbf > 0 )); then
    #echo "$txjson" > /tmp/tx/$txhash
    sql="${sql}UPDATE exp_mempool SET is_processed = TRUE WHERE hash = '$txhash' LIMIT 1;"$'\n'
    i=$((i+1))
    continue
  fi

  r=$(echo "$txjson" | jq -r '. as $tx | .vout[] | select(.scriptPubKey.type == "pubkeyhash") | $tx.txid, .value, .scriptPubKey.addresses[]' | grep . || true )
  if [ ! -z "$r" ]; then
    r=$(echo "$r" | awk 'NR%3==2 {printf("%d\n", sprintf("%.08f", $0*100000000)); next} {print $0}' | awk '{printf "'\''%s'\''," (NR%3==0?RS:FS),$1}')
    sql=${sql}$(echo "$r" | sed -e "s/^/INSERT INTO exp_mempool_tx(hash, amount, address_to) VALUES(/" | sed -e 's/,$/);/')
  fi
  sql="${sql}UPDATE exp_mempool SET is_processed = TRUE WHERE hash = '$txhash' LIMIT 1;"$'\n'
  i=$((i+1))
done
tsnow=$(date +%s%N | cut -b1-13)
opsec=$(echo "scale=2;$i/(($tsnow-$tsstart)/1000)" | bc)
p=100
printf "$p%% ($opsec tx/sec)\r"
echo
sql="${sql}COMMIT;"

Note the condition regarding RBF. I simply skipping such transactions so they never have a chance to be parsed and inserted into exp_mempool_tx from which I am doing my balance monitoring.

So the transactions with RBF supported should wait to be fully inserted into blockchain and picked up by my blockchain explorer.
4  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 02, 2019, 04:30:27 PM
If you're planning to do this as a "protection against double spend" like what you've said somewhere above, it won't help.
If the double spend tx's fee is higher and a mining node accepted it/both, the one with the higher fee will be mined 1st.

Interesting... So RBF allows a specification of a different destination address, which means that the attacker can successfully implement double-spend.
.. should I look into nSequence of the transaction I am accepting in order to determine if RBF is enabled on it perhaps?

It seems like the discussion is now off-topic based from the OP, perhaps you need to create a new thread

Uh oh.
The blockchain explorer on bash (as well as mempool explorer BTW) that I published above works just fine.  So the problem is solved.  Now we just talking about deployment-related issues which is somewhat within topic. Smiley
5  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 01, 2019, 02:26:09 PM
The reason behind the reply is: blockexplorers usually have more than one nodes to connect to more peers than a regular user's node,
so if your transaction's TXID can't be seen by them, most of the network's node must have dropped that TX.

Does the bitcoin core provide the api to:
1.) Enumerate the other nodes connected to mine.
2.) Ask these nodes if they have a specific txid in their mempool.

Or it is just easier to re-broadcast every hour?  Grin
6  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 01, 2019, 02:15:01 PM
Technically, no. Nodes would still drop your transaction after some time but if you rebroadcast it periodically, you'll ensure that their mempool would contain your transaction for most of the time.

Alright. Cool.  So I will periodically re-broadcast the transactions that I accepted (provided the service for) that where not included into the blockchain to ensure the tx stays in the mempool and will get mined sooner or later.  Wink
7  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 01, 2019, 02:04:54 PM
What do you mean "stuck in the mempool"?
By default any unconfirmed tx will be dropped from a "node's mempool" after 2weeks (each node have their individual mempool).

I mean if the tx has low fee, it appears to me that it can get stuck in the mempool for the prolonged amount of time and then get dropped from it without any insertion into the block.

The solution is: do not finalize a deal without any confirmation.

That is the solution which works in theory.  In practice people do not want to wait.  They want everything and right now.

An indirect reply to post below: If you're not seeing the txid in any blockexplorer,
chances that it was dropped by most nodes is high.

Txid??  Huh The transaction hash you mean?
 Anyways,  I don't use "any blockexplorers".  I am using a bitcoin core node in pruned mode.
8  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 01, 2019, 01:48:19 PM
Even if that unconfirmed tx was previously dropped from the mempool?  Undecided
If it was dropped, then he can re-spend the UTXO as long as it was removed from his transaction history.
If not, the user can manually delete it using -zapwallettxes command.

Aha.  So what if I will re-broadcast the tx which is stuck in the mempool every hour or so - will there be any penalties? Will it improve the chances of this transaction not to be dropped from the mempool?  Any elegant way to detect the moment when the tx gets dropped?

Edit: I was also wondering why the transactions gets dropped from the mempool.  Why not to store them in DB and simply wait for a good moment to insert them into the block based on the fees specified in them?  There is no risk of DDOS for the bitcoin infrastructure due to the minimum fee of 1k Satoshi per kb.
9  Bitcoin / Bitcoin Technical Support / Re: mempool explorer on: October 01, 2019, 01:39:51 PM
The question is - will the owner of the transaction be able to broadcast another transaction to the different address which depletes UTXO from their previous transaction to my address?
By default, Bitcoin core won't allow you to re-spend a UTXO previously used by an unconfirmed tx.

Even if that unconfirmed tx was previously dropped from the mempool?  Undecided

Edited:
I am trying to figure out solution which will protect me from double-spend attack in case if I accept the tx from the mempool but then it will be dropped from it.
I wonder if I should re-broadcast such tx myself say every hour in case if they stuck in the mempool.
10  Bitcoin / Bitcoin Technical Support / mempool processing is important on: October 01, 2019, 01:13:49 PM
I am reading articles like this one: https://www.coindesk.com/charts-determining-ideal-block-size-bitcoin

Quote
A side note on ‘coffee’
Users of the bitcoin network, and in particular businesses, tell us that fees have increased to the point where paying for coffee and other even smaller use cases (such as ad network payments) are not viable anymore.

One can hear about that "pay for a coffee with BTC" argument over and over again even in papers like WJS.
I am failing to understand how come the transaction fees become so high.
Say the Bitcoin block size is 1MB.  Even with a huge fee like 50k Satoshi per 1kb it follows that only 0.5 BTC will go to the miner from the all block transactions.  With a current block reward of 12.5 BTC per block, it is unclear what is the purpose of such high fees from financial perspective.  Simply put, there is not much difference for the miner between high fees or low fees.

I think that fees should be voluntary but progressive, depending on the amount of BTC being transferred.  The guy who transfers say 1000BTC should not rely on say electrum dynamic fee estimation and should have no problem setting up a really big fee like 1m Satoshi per kb, and expect his transaction to be included into the block right away.  At the same time, the guy who buys a coffee for a few $ should put a minimum fee and at the same time expect to get a service (in this case the transaction fees for him will be only about 2 cents).  In this case, the service provider should use a mempool explorer and get the transaction out of there.  If it drops from the mempool, he should pick it up and re-broadcast.  I doubt the coffee buyer will even try to double-spend by waiting for his transaction to be dropped from the mempool and then broadcasting the one with same inputs but different output right away.

The above described sounds like a common sense to me.  So I will continue to use mempool explorer.  I can't see any problem here.
11  Bitcoin / Bitcoin Technical Support / mempool explorer on: September 29, 2019, 11:28:34 PM
I am still thinking that I should use the mempool and provide the service as soon as I see the correct amount designated to my address. It was pointed out to me that in rare cases, the transactions may be dropped from the mempool and that is why it is unreliable.  I was wondering if I can save the transaction in my DB and then detect if it disappeared from mempool and re-broadcast it myself.  It is still unreliable since my server can go down and fail to re-broadcast, but such risks are acceptable by me.

The question is - will the owner of the transaction be able to broadcast another transaction to the different address which depletes UTXO from their previous transaction to my address?  What is going to happen if such transactions will appear in the mempool at the same time (which try to spend from the same UTXO more than it actually has)?
12  Alternate cryptocurrencies / Altcoin Discussion / Re: Will crypto really go to zero? on: September 19, 2019, 01:22:02 PM
I'm sure Vitalik said that because of his concern for cryptocurrency, ...

 Grin

And one more time: Vitalik never said that.  Please check your sources.
13  Alternate cryptocurrencies / Altcoin Discussion / Re: Will crypto really go to zero? on: September 18, 2019, 04:30:44 PM
I would like to repeat:

Vitalik never said the things that OP is ascribing to him.

 Grin
14  Alternate cryptocurrencies / Altcoin Discussion / Re: Will crypto really go to zero? on: September 17, 2019, 02:58:24 AM
Back in the day, Vitalik once said that crypto will be going to zero.

Dear OP, please be so kind and check your sources before starting the conversation.

In the objective reality, Vitalik never said any such thing.
About a year ago there was an article: https://techcrunch.com/2018/09/02/the-collapse-of-eth-is-inevitable/
in which Jeremy Rubin made a prediction:

Quote
Here’s a prediction. ETH — the asset, not the Ethereum Network itself — will go to zero.

Then Vitalik made a response: https://www.reddit.com/r/ethtrader/comments/9ch5ls/comment/e5av470
in which he essentially agrees with lots of criticism and proposed the ways out of it.

And thats about it.  Not a word was from Vitalik related to "crypto will be going to zero".

 Grin

I would assume that this is the problem of humanity as a whole, isn't it?  The misinformation.
15  Alternate cryptocurrencies / Altcoin Discussion / Re: Will crypto really go to zero? on: September 14, 2019, 03:25:12 AM
Back in the day, Vitalik once said that crypto will be going to zero.

I would point out that Vitalik is not very good forecaster.  For example, in his whitepaper he suggested to use Ethereum contracts for DApp development of a file storage services.  Well, nobody using it as of now.  Take Haven app (https://gethaven.app/), for example - they simply using IPFS w/o any contracts; w/o blockchain even. Smiley
Regardless, what are the use cases for Ethereum? Trustless gambling and trustless currency exchangers?  Anything else?  Can they be implemented via Bitcoin script?  Pretty sophisticated stuff can be coded on Bitcoin (see Lightning).
At the same time, other alt-coins like Monero or ZCash for example, actually have evident use cases - like actual transaction anonimisation.

I am not sure what the other altcoins for.  Undecided

As for the question itself, there is simply no way crypto will be going to zero.  Cryptocurrencies bring the money back to people - so they are much better than the money issued by the governments.  Crypto is just too good to go down.
16  Bitcoin / Bitcoin Technical Support / Re: Parse recent transactions with bitcoin core in pruned mode on: September 08, 2019, 03:16:02 PM
You can still accept payments, simply use the master public key to derive addresses.
Once your core-server goes back up, all your payments (received when it was down) will get processed again.

Hmm... I had an impression that I have to use seed to generate addresses by certain derivation path.  But it is possible to use just bip44 public key to generate addresses by derivation path as well?
17  Bitcoin / Bitcoin Technical Support / Re: Parse recent transactions with bitcoin core in pruned mode on: September 08, 2019, 02:10:40 PM
You are talking about RBF case? If so, please provide the info how the situation can be handled properly.  Personally, I cannot see how.  

You should wait for at least one confirmation before inserting it into your database.

In order to avoid 51% attack on blockchain?  What is the reason behind it?

The node should provide some kind of pool of revoked transactions, but I cannot find it anywhere.

There are no 'revoked' transactions.

Transactions are only final once they got included into a block. Afterwards they can not be 'revoked'.
Transactions which aren't confirmed yet, are by far not final. They also don't have to confirm at all. They just have been broadcasted which basically means "i want to do the following: send X from A to B".

They are kinda revoked from my perspective.  The idea that one transaction can replace another one because it has a higher fee is a mess.  Grin

Was there a case when the valid signed transaction that appeared in the mempool wasn't mined I wonder?

And, actually, I am using this tool for the shop.  At least by now it is much better than it was before - relying on third party to get the balance.

Usually, you don't need to pregenerate so much addresses. Just generate them whenever needed.

Edit:
That would require two servers to be online in order for the service to accept the payments - the one with Bitcoin Core and another one with the DB of a service.  And if, for some reason the server with Bitcoin Core goes down, ... I will not be able to accept the payments?

Edit2:
* Of course I can't hold Bitcoin Core on the same server with the payment service itself - that would be a huge security flaw.
18  Bitcoin / Bitcoin Technical Support / Re: Parse recent transactions with bitcoin core in pruned mode on: September 08, 2019, 01:17:15 PM
I hope you are using that tool just as a personal project without much more use.

You should - under no circumstances - rely on this tool if you are running a webshop or any other kind of service where the payments are automatically handled.

Adding something to your DB first, and later checking whether it really confirmed is highly error-prone. It for sure is good enough for a personal research project, but is definitely not suited for a business / something business-like.

You are talking about RBF case? If so, please provide the info how the situation can be handled properly.  Personally, I cannot see how.  The node should provide some kind of pool of revoked transactions, but I cannot find it anywhere.

At least for now I can only display the balance as unconformed (which was grabbed by mempool explorer) until it will be validated by the blockchain explorer.

And, actually, I am using this tool for the shop.  At least by now it is much better than it was before - relying on third party to get the balance.
19  Bitcoin / Bitcoin Technical Support / mempool explorer on: September 08, 2019, 04:37:21 AM
Alright.

So in addition to abovepublished blockchain explorer I made another bash script - mempool explorer.
The script starts periodically (every minute) and moves all mempool transactions into DB, takes a batch of 500 from unprocessed/unflagged ones and through getrawtransaction retrieves an info on each of them; all successfully retrived addresses along with amounts and transaction hashes are dumped into another table and the respective mempool transactions are flagged as processed.  Then I am determining if any of the dumped transactions have outputs on my addresses and if they do, I am incrementing the balance in my DB by the value of the output.  Since RBF are possible I am waiting until blockchain explorer will discover a block and in case RBF indeed occurred, it will return the balance to the right value.  Blockchain explorer also deletes transactions that it is found in the block from the table with which mempool explorer works.

Everything seems to be working nice and smooth.  Every minute the mempool explorer picks up a few hundred new transactions, quickly processes them and updates the balance table if anything new appeared.

* I also noticed that LEFT JOIN between the table with addresses picked up from the block/mempool and between the table with addresses which balance is checked can take quite a while even with indexes on hashes of transactions.  So I decided to perform this operation on the separate server.

Thanks everyone for the help.
20  Bitcoin / Bitcoin Technical Support / Re: Parse recent transactions with bitcoin core in pruned mode on: September 07, 2019, 01:51:41 AM
Transactions can be dropped out of the mempool without being confirmed.
For example if RBF is enabled.
He can trivially bypass that by double-checking the database entries periodically until there are multiple confirmations. Conflicts are marked accordingly by the software anyway. Hence:

Not entirely true, but yes.

Huh oh.
So if I will pick up the transaction from the mempool and update the balance in my DB.  Then if due to RBF, I will pick up another transaction with a higher fee.  The hash of that transaction will be different (since fee is kept inside the transaction).  But how I will determine if this new transaction should replace the prior one so instead of increasing the balance in my DB I would just keep it as it is?
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!