It is being handed over to the script as an argument when calling it (%s is the TXID):



Then it depends on the scripting language how to access it.

For a shell script, you would use:

For a php script:


walletnotify will run each time:

• you receive a transaction associated with your wallet
• you send a transaction
• an incoming transaction receives its first confirmation

For X incoming transactions, it will be run 2*X times in total.

Note that you can set up core to be run on the testnet, to see how it exactly behaves and how to make use of it most efficiently.



P.s.
I appreciate that you don't want to use some 3rd party services and want to be in full control over the funds - basically how it is supposed to be.
If you have any concerns or questions, even going further than just setting this up, feel free to ask.
There are a lot of people here who appreciate that engagement and would help you with your questions / concerns.

Posted several times already.

If you can't read, it is your fault. Learn to read, learn to comprehend what you read.. then look for it again.
If your IQ is higher than the IQ of a slice of bread, you will find it.

This does just mean that the website does not use https.
This is definitely NOT an indicator for the authenticity of a website.

I'd expect any phishing site not created by completely incapable people to have a TLS certificate. You can get them for free.

You had 5 clients in 3.5 years and scammed 3 of them.

At least 4 user have shown 4 proofs that you are a scamming piece of sh*t. Are you just trolling or seriously mentally ill ?

You are right, but this makes me wonder why electrum states that versions < 3.3.4 (including 3.3.3) are vulnerable to the phishing message.

Maybe that's just a typo on their website ?

Well, you'd call the script with the transaction id as a parameter:


And inside of your script (shell, php, whatever..), you could call

to get all necessary data from the transaction.

Afterwards process the data as you need and/or fill your database.


You wouldn'd directly check whether address X received a transaction, but you'd call that script upon receiving any transaction.
Then using gettransaction, you'd get all necessary information (receiving address, amount, etc.. ) for further processing.

While i can't speak out of experience, i don't think you'll have performance issues.

walletnotify and blocknotify execute a shell script upon receiving a transaction / block.

You probably won't be able to process thousands of transactions each minute with a raspberry pi, but since the network can't handle so much itself you shouldn't get any problem with a medicore VPS / whatever you are using.

The current amount of transactions the bitcoin network can handle is at roughly 200 per minute.
Besides the fact that i doubt you alone will fill 50% of all blocks, it definitely should be possible without performance issues.

Why don't you use the master public key to derive public keys and addresses while the private keys are in cold storage ?
That way, you would directly accept payments into your cold wallet and would save on transaction fees.




You could use walletnotify to get notified each time the state of your wallet changes (i.e. transaction received, transaction sent, first confirmation on a TX).
That'd be more efficient than having a cronjob checking the addresses each X seconds/minutes.

If you require more than 1 confirmation, you can combine this with blocknotify, to get notified each time core receives a block.
If walletnotify says that you received 1 confirmation on transaction X, you can be sure the next time blocknotify is called, this TX has one more confirmation.

AFAIK, the vulnerability was found in 3.3.2 and the update to 3.3.3 didn't completely fix the issue.
So 3.3.4 was the first version which is safe against those phishing message shown by the electrum server.

Therefore, such a message can be shown in 3.3.3, yes.


But since the current version is 3.3.8, no one should actually be using 3.3.3. Unfortunately this is not the case yet.

While this may be possible, i think this doesn't make much sense, does it ?

(Especially) signature campaigns focus on good post quality.
Merit does - more or less - directly reflect exactly that. Badges for good reports are not an indication for high post quality.

Being a good poster and bringing value in terms of knowledge into this forum does not automatically mean engaging in the 'forum politics' (or call it whatever you want).


But i agree with your last statement, everyone loves shiny internet points 

That's no sorcery, but IDNA encoding.

The following cyrillic letter is the cause of that:

This is quite frequently used by phishing sites to deceive others into clicking on a 'known' URL.
That's a known problem with unicode domain names.

I think that's the point.

The more people start reporting worthless spam posts, the more will be deleted.
And more spam being deleted means people will actually focus on not spamming this forum for a few cents.




I don't think that would be a huge issue.

From the report-page:

The badges would be for good reports. Reporting 100 posts which shouldn't be reported will not get anyone closer to a badge.
And then the reporting behavior might be changed.

But another requirement for the badges could also fix this potential problem.
Combine a minimum amount of good reports with a minimum amount of accuracy. Then people won't start reporting hundreds of posts just to get a few good ones out of it.

If the transaction has the RBF-flag set (Replace-by-Fee), then yes. He could simply bump the fee.

If the flag is not set, you either have to do a CPFP or ask him to send another transaction.
But sending another transaction is not recommended because both may confirm ending up in you receiving the double amount.

So the best (and fairest) options are either a RBF by the sender or a CPFP by you.


And yes, he still can cheat you until it is confirmed.
If the RBF flag is set, he can replace the transaction with another one sending the funds to a completely different address.
That would be even possible without the flag set, even tho being not that easy to achieve.




If you are refering to bumping the fee (i.e. RBF), nothing will happen.
The bumped transaction will confirm and the old one will never be able to be included into a block.

IMO there is nothing wrong with working for FIAT and converting it into bitcoin.

I mean.. you mostly can't earn any other currency than the one used in your country.
But you can exchange your earned money into a different currency.


While the point of view of not treating bitcoin as an investement is good, i don't think working for USD and exchanging it to BTC has to be called investment per se.
If it is the only way to earn BTC.. why not?

In the end it doesn't matter whether you directly get BTC for your work, or FIAT which you then exchange (despite the fact that you'd be boosting the usage of BTC which honestly would be a good thing).

The transaction can not confirm before the first one does.

However, they can confirm in the same block and you are also able to already use that UTXO.

This is one way to 'boost' a transaction with a low fee. It is called Child Pays For Parent (CPFP).
If you need that transaction to be confirmed fast, create a TX using the unconfirmed UTXO as input and choose a fee which is high enough to pay for both transaction.

If the fee / size of both transactions is higher than other transactions, they will be preferred by the miner and therefore confirm relatively fast.

The armory log should (not sure about that since i am not using a mac) be located in


and is named armorylog.txt.

Use some text-/code- sharing platform to upload it (e.g. pastebin and provide us the URL.

To be more precisely, flags are valid if a given number of user in your trustlist support it.
For a type1-flag, that's 1 more supporting than opposing and for a type2/3-flag that's 3 more supporting than opposing.

Since probably the majority of user didn't touch their trust list, DT 1/2 is what counts for them. This also applies to guests.

Generally, it is advised to adjust your trustlist to be less dependent on DT votes.

Flag created: https://bitcointalk.org/index.php?action=trust;flag=599

I think that still would be fine.

The original crypto stamp isn't an etherum stamp either, but an ERC-721 token.

Using something like bitcoin / omnilayer should be comparable to ethereum / ERC-token. Or am i missing something ?
I am not really familiar with omni, but as far as i know thats pretty similar ?

ChipMixer is not a scam.

Do you really think they would scam you for 1 BTC ?
Hell.. even for their signature campaign on this forum, they are allocating  ~2 BTC per week.


chipmixerwzxtzbw.onion is definitely the correct URL. That's stated on their clearnet site.


When did you email the support ? Is your session still valid ?