< kanzure>
for manually testing hard-fork scenarios (when hard-fork clients don't supply adequate test infrastructure), it should be sufficient to have two regtests that have common history and then are kept separated, right?
< sipa>
kanzure: invalidateblock is your friend
< kanzure>
ah that could work for this.
< kanzure>
thank you
< kanzure>
also: there should be a walletnotify that triggers a notification with pre-configured memo field after configurable n blocks.
< kanzure>
which should solve basically all of the payments integration use cases
< promag>
you mean alertnotify?
< sipa>
that's for alerts
< sipa>
not for payments
< promag>
walletnotify only notifies txid right?
< sipa>
yes
< promag>
then I don't understand what kanzure is saying
< sipa>
he wants a notification only when it gets a spefific number of confirmations
< sipa>
that's configurable per address/label
< promag>
why?
< kanzure>
haha what do you mean why?
< promag>
having that may cause lots of notifications
< kanzure>
yes i agree it will cause lots of notifications (due to lots of internal reasons)
< kanzure>
but having many notifications is better than no notifications
< promag>
but there is a notification: blocknotify
< kanzure>
walletnotify on first confirmation isn't useful-- you need the notification to be triggered after n notifications
< kanzure>
blocknotify is not the same thing
< kanzure>
think about your typical idiot web developer-- the simplest possible solution is a notification when the payment is well-confirmed
< promag>
because of forks?
< sipa>
the idea is that you can check number of confirmations of all your oending transactions after each block
< sipa>
as those are the only times ehen confirmationd can change
< kanzure>
yes but that's more work for the web developer-- if you give them a notification, it's almost zero additional work, and it's easier than setting up stripe
< sipa>
kanzure: there are other complications... you need to keep track of your oayments and their confirmation status, what theybwere for, make sure that is in safe storage (so that after a system failure, you don't end up with payments without knowing what order they are for, ...)
< sipa>
but yes, having a notification for a specific number of confirmations would be useful - except this now also needs backups inside core
< promag>
been there, and walletnotify is not a good solution, you can easily lost notifications, you can have lots of pending transactions, etc.. the overhead can be huge IMO
< kanzure>
lost notifications are a problem, and yes wallet backup procedures become more important, but they were important anyway
< promag>
I always thought of a thing like postgres wal, that can be replayed
< sipa>
i think the only correct solution is that you keep track of confirmations yourself, and after every walletnofiy/blocknotofy you check your outstanding payments again
< sipa>
even ignore the txid passed in walletnotify
< kanzure>
sipa: the exercise was how to minimize the total integration complexity for a web merchant
< sipa>
kanzure: yes, and i don't have a good way of doing that that doesn't result in more risks
< kanzure>
sipa: more risk is probably okay, since the total cost of the integration is so low, more resources can be spent by the integrator on e.g. backup procedures.
< sipa>
backup procedures may not be enough
< sipa>
if your solution relies on bitcoind persisting the requested notifications
< sipa>
as that effectively requires a backup system integrated into bitcoond
< promag>
what I think is the best for the moment is to keep track of new blocks, and check pending transactions confirmations (without doing too much RPC)
< kanzure>
promag: my exercise was "what is the 5 minute integration" and walletnotify after 6 blocks would do the trick, even with extremely high risk
< sipa>
and if you don't rely on that, your web developer needs to deal with restarts and lost notifications anyway, at which poijt as simple "check all unconfirmed txn after every block" will be easier and safer
< kanzure>
check pending transactions on each blocknotify would involve persisting and doing read-write on that data outside of bitcoind, this is going to take more than 30 seconds for an idiot to implement
< sipa>
kanzure: *every* solution will require persisiting information outside bitcoind
< sipa>
how else will you know what your orders are that are being paid, at the least
< kanzure>
i think it can be minimized and greatly reduced
< kanzure>
to only one write requirement somewhere. and minimal reads.
< kanzure>
anyway, i don't have a specific proposal
< sipa>
we've discussed this many times, but persistance of such notification requests is a pain
< sipa>
and effectively not something we can do safely now
< promag>
IMO there is no 5 min integration
< sipa>
this is part of the reason why accounts aren't safe to use, as well
< sipa>
you can't guarantee that a backup will happen between the creation of an account address and the receipt of the payment
< kanzure>
why not? tell the user to do the backup.
< sipa>
when?
< kanzure>
whenever you please
< sipa>
no, not whenever you olease
< kanzure>
there should be a backupwallet hook
< sipa>
if you crash after handing out the address, and before making a backup, you lost a customer
< kanzure>
then you should only return from getnewaddress after the backup is complete..
< sipa>
yes, which would require a built-in backup solution in bitcoind, which we don't have
< sipa>
and generally, since you need to store payment information outside anyway, why bother duplicating the complication
< sipa>
i think a paymemt watching layer in python with sql integration or so would be very useful
< sipa>
which deals with persisted orders, recovery after restart/crash, RPCs with bitcoind, ....
< promag>
you can use multiple nodes to scale or even have redundancy with watchonly
< promag>
sipa, is it worth improving CheckBlockIndex
< promag>
?
< kanzure>
sipa: that layer would be immensely useful, and would also abolish many merchant's requirement for a payment integrator api service thing. e.g. provides them a reason to run a full node.
< sipa>
promag: no opinion
< sipa>
benchmarks help
< cfields>
uhmm
< cfields>
BlueMatt: ping
< sipa>
*drumroll*
< cfields>
BlueMatt: i think 57edc0b0 is pretty busted?
< BlueMatt>
yo?
< BlueMatt>
why is that busted?
< cfields>
pretty sure i ACKed that too quickly :\
< BlueMatt>
cfields: well I think you mean one of the associated commits, cause that commit itself is literally only a rename
< BlueMatt>
busted how?
< cfields>
BlueMatt: grr, nm.
< BlueMatt>
there is the static seeds issue
< cfields>
dammit, it always clicks after i do the ping.
< BlueMatt>
which is fixed in #11512
< gribble>
https://github.com/bitcoin/bitcoin/issues/11512 | Use GetDesireableServiceFlags in seeds, dnsseeds, fixing static seed adding by TheBlueMatt · Pull Request #11512 · bitcoin/bitcoin · GitHub
< cfields>
BlueMatt: yea, nm. ignore.
< BlueMatt>
k
< cfields>
BlueMatt: i have several patch series that add an m_automatic_connection for addrman connections
< cfields>
i couldn't unsee, thought the logic was reversed
< BlueMatt>
heh
< spudowiar>
Can nHashType ever be zero?
< jonasschnelli>
spudowiar: 0 would be an undefined value
< spudowiar>
Thanks
< jonasschnelli>
spudowiar: look at BCH,... they use also it's own SIGHASH-type...
< sipa>
i think 0 is totally valid
< spudowiar>
ok
< sipa>
but nonstandard
< spudowiar>
Doing some stupid BTG support for TREZOR
< jonasschnelli>
Grml.. BTG!
< spudowiar>
And they decided to use SIGHASH_FORKID with non-BIP143 signatures
< spudowiar>
So I need to rewrite all that
< jonasschnelli>
I would prefere if Trezor would not support BTG. :) Sorry for off-topic
< jonasschnelli>
(but I understand it)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #11587: Fix warnings when building with -Wthread-safety-analysis (master...–Wthread-safety-analysis) https://github.com/bitcoin/bitcoin/pull/11587
< spudowiar>
jonasschnelli: Believe me, so would I :P
< jonasschnelli>
heh
< Alkhara>
Anyone willing to answer a question 1:1 that has to do with source code but not directly for the Bitcoin project please DM me. I don't want to off-topic but you guys are probably the best source of information on this.
< sipa>
Alkhara: bitcoin.stackexchange.com
< earlz>
Is it possible to modify the gitian scripts to cross-compile bitcoin-qt for ARM?