|
There are several concepts here:
when you create a "normal" transaction and broadcast it, it is "instantly" received by (most of) the nodes of the network... Not really instant, but it won't take more than a couple of seconds...
Once a node receives your transaction, it's put in the mempool of each individual node. So, most nodes will know the transaction exists, they know which unspent output was spend and which address was funded (at least, for a "normal" transaction, in theory there are different kinds of scripts, so your transaction doesn't *have* to fund an address per sé)
So, the moment you "send" a valid, standard, average fee transaction, most of the nodes of the network will have your transaction in their mempool in mere seconds, and most wallets monitoring the receiving address will show an UNCONFIRMED transaction allmost instantly.
In order to get your transaction into block (get a confirmation), a miner has to create a block containing your transaction, and find a block header (trough iteration) whose sha256d hash is under the current target. By adjusting said target every 2016 blocks, the network makes sure the AVERAGE time between two blocks is ~10 minutes. I have to point out that it's an average time... 2008 blocks that are found after 2 minutes and 2008 blocks that are found after 18 minutes => 10 minutes on average, and the diff won't be adjusted!
Wether or not a miner picks your transaction from it's mempool to be part of the block they're trying to solve, they usually look at your transaction fee (in sat/vbyte). Important fact: the fee has nothing to do with the monetary value that's being transmitted and only depends on the transaction size (in virtual bytes)
|
|
|
|
NotATether's sollution works... If you want an easyer method that allows you to greatly simplify the backup procedure, you could also use electrum, let it generate a seed phrase, write down this seed, then go to electrum's console and do: wallet.change_gap_limit(10000) wallet.storage.write() listaddresses() Then you'll get a list you can import into a db.. Do prepare to wait a LOOOOOONG time... A 10.000 gap limit isn't small... TBH, my sollution isn't per defenition better than NotATether's, it's just differrent  |
|
|
|
--snip--
I was totally ignorant about this phenomenon LOL
So if I have the private key then would I be able to see the actual balance and would be able to spend using Electrum? I guess I would?
Electrum doesn't fetch the unspent output from the electrum node... So, no, if you had the private key you wouldn't be able to spend the coinbase reward using electrum's gui... That being said, you could theoretically use electrum to sign an unsigned raw transaction spending the coinbase reward if you used a different tool to create said transaction... At least, i guess this would work... Never tried it tough... Maybe somebody else did try this and could weigh in? |
|
|
|
|
Maybe the lenght of this "text", the first character, the last character and potentially some description of the character set might be usefull (for example, only capital letters, alphanumeric,...).
Don't post the rest of the "text" tough, don't give it using a PM either... In case your seller used a weak encryption scheme, sharing the "text" might lead to loss of funds...
I'm not sure if anybody will be able to help you, but the description "some text" defenatly isn't enough...
|
|
|
|
|
You could theoretically find an online form that allows you to push your transaction to several nodes... Some nodes might have different settings regarding to their mempool. This being said: even if you find such a node, your transaction will probably end up in their mempool and their mempool alone, since their peers probably won't allow your transaction in their mempool when it's broadcasted to them... So your odds of getting such a transaction confirmed "just like that" is very small...
I guess you're stuck with either waiting untill the average feerate drops dramatically, or you can find a BIG mining pool that's willing to include your transaction into the block they're trying to solve... You'll probably have to offer them a big reward for doing this tough...
|
|
|
|
Thanks for testing I'm not going to reply to each individual test, but in general, i can tell you that the GUI problems are known and on my to-do list.... They'll get partially fixed in the next release which i'll roll out later today or tomorrow. I expect them all to be fixed once i roll out an actual beta release (we're still in pre-alpha at the moment) As for the rest: i've read all your replies with great care, and i've seen a couple of features that are defenately doable, so i'll add them to my to-do list.  |
|
|
|
@bitmover: offcource, by the time i looked at the transaction in question, it had 3 confirmations already, so it was pruned from my mempool before i could track down the source of the problem  . My gut tells me that the previous issues were due to the fact i had ridiculously small settings for my mempool (max 50 Mb, max 2 hours before pruning), and the current issue *might* have been because the transaction was mined between testing the non-TLS and the TLS version??? I'm not sure tough, but like i said: can't test anymore because the transaction ended up in a block before i could have a look at it I haven't really gotten around to the gui, enduser stuff... But your proposal (to concat the 2nd and the last 2 lines) sounds good... I'll do that when i have some dev-time tomorrow... I'll also try to test a bunch of transactions between the TLS and non-TLS version. The non-TLS version will be stopped pretty soon (there's no added value to be had from running a non-TLS version), but i'd like to be sure the issue with transactions popping up on the TLS version and not on the non-TLS version aren't caused by a bug. Thanks for testing! It's highly appreciated By the way, in case more people willing to test pop up: you don't really have to use the form (for now), you can just post the txid directly to https://www2.mocacinno.com:8082/page/feechecker using tools like postman... This makes it easyer to bulk-test or debug  |
|
|
|
In the meantime, based on the feedback in this thread, i've fixed following issues: - For some reason, i had my node configured with maxmempool=50; mempoolexpiry=2(probably because i was strapped for resources a while ago). Now, i've changed these values to 250Mb, 1000 hours... Should be better this way :-)
- Based on Joel_Jantsen's feedback, i've changed the title of the feechecker page a little bit... The code isn't actively running tough, but it's already present in the github repo
I've also setup redirects from my old site to the new daemon, since the old feechecker didn't work anyways... Data POSTED to feechecker.php is redirected to the new page aswell... The next couple of days, i'll probably try to fix some of the gui elements, links, layout problems and do a better check of the feechecker... Once again: if somebody finds any bugs, don't hesistate to let me know! |
|
|
|
|
No, if you lose your private key (or your "encoded" private key in any other form, like a seed phrase, an sss scheme, a QR code, a brain wallet passphrase, ...) your can no longer access your funds. There are no ways around this. You need your private key to sign the transaction(s) spending your funds.
You look at it from the perspective of somebody losing their key (which sucks), but you can also look at it from the security perspective: bitcoin would not be secure if somebody was able to retrieve keys "out of thin air".
There are exceptions, but nothing you (as a normal user) should worry about... Since i don't think you'll be using anything but a standard wallet (which is fine btw).
|
|
|
|
@bitmover and @SFR10 Thank you both for testing @bitmover : I'm using my own node, but i might have to edit my config so i keep more transactions in my mempool.... As for the problem shown by SFR10: i have no idear yet... I'm back @ the office on monday morning, and i'll immediately have a look at this when i arrive. Theoretically, nothing was changed between the two versions of the tool except adding the certificates to enable TLS... But you know, pre-alpha stuff is not well-tested, so there's probably a bug somewhere. I'll probably stop the non-SSL version monday morning, there's just no use-case for a non-TLS version that is not covered by the TLS version. The github repo I posted in the OP contains the TLS version anyways, i just compiled the code pre-TLS and started running it for the non-TLS version, then i modified the code and ran it uncompiled for the TLS version. |
|
|
|
--snip--
In this crisis time (high fees I mean) this will be a great tool for bitcoiners. By the way this is my first time visiting your site mocacinno.com. I wonder how much traffic you get a month? It's informative after all.
Good question... I honestly never look at my server stats... Eventough i'm strongly against cloudflare, i have enabled cloudflare on my main domain a long time ago (it's not like i handle really privacy-centric things anyway) and those guys say it's about ~400 uniques/day, eventough many go to my blog (which also contains outdated info... I haven't created a single post in a long, long time) BTW: the TLS version is live @: https://www2.mocacinno.com:8082/ |
|
|
|
The main functionality of my website (mocacinno.com) was written back in 2017. IIRC, i was running core version ~0.12~ish (i don't update my node all that often). Since then, loads has happened in our ecosystem... And my "usefull" tools became outdated and no longer functional. I've been thinking about rewriting my site, but over the years so many things were "added on".... So i needed a radical new way of working, changing just a little bit won't do, it needs to rewritten completely and all the sub-tools need to be moved manually... I'm currently in the process of rewriting the TOOLS section of my site in go... I'm thinking about using a small footprint webserver in go next to my main webserver, i'll then redirect all requests going to my tools to said go daemon. That way i can fix my tools while i'm in the process of thinking about how to move all that data without breaking stuff. Because of the current state of the mempool, i'm releasing the first tool, eventough it's currently in pre-pre-pre-alpha stage. http://193.70.78.148:8081/page/feechecker => Non-TLS had no added value, so i no longer run a service on this port, use the TLS version instead TLS version => https://www2.mocacinno.com:8082/page/feecheckerWith this tool, you can check wether or not your transaction is in my mempool AND if you added a sufficient fee. You can POST the txid directly to https://www2.mocacinno.com:8082/page/feechecker if you don't want to use the form. Bug reports are welcome BUT you'll have to realise this is pre-pre-pre alpha... my immediate TO-DO list: I'll defenately add TLS (https)- input sanitation
- fix the menu... At the moment, clicking any link other than "using the feechecker tool" will send you on a wild goose-chase over one of my many ip's and open ports... Also, images and layout WILL break if you do something else than testing the feechecker
- add more functionality
Also, this is not a linux service (yet). If it crashes, it crashes and it'll only start when I start it again... When i go to a beta phase, i'll make sure the service restarts if it crashes In case you want to fix bugs yourself (or steal my code) => https://github.com/mocacinno/mocacinno.comEDIT: just a little sidenote: i'll be gone during the weekend, i'll be back on monday morning to read potential bug reports |
|
|
|
Well... There are a couple things you can do to lower the fee(s), some have already been discussed in this very topic, some are already implemented by you (but i still listed them to be complete): - pay-to-many: don't send individual payments, pay in bulk
- consolidate your unspent outputs whenever there's a dip in the average feerate. Tje fewer unspent outputs used as an input, the smaller your tx size.
- start using a native segwit wallet, force people to give you a native segwit address
- start using the lightning network
- don't pay every week... accumulate the funds and pay once/month
- switch to altcoins... I'm not a big fan of ETC or LTC, but when the average feerate is >140 sat/vbyte, i would understand a campaign manager if he/she asked to pay using an established altcoin for the time being...
The current average feerate is bad... There is no way around this i'm afraid. Everybody that wants a decent shot of getting his/her tx in a block in a reasonable timeframe will have to pay up (or use viabtc). You can lower your feerate by using above "tricks", but the feerate won't magically drop to 20 sats/vbyte i'm afraid. |
|
|
|
|
Well, you're an unknown newbie... 20€ beforehand, 280€ afterwards does indeed mean that the person taking your deal doesn't lose money, but it also means that the odds of you dissapearing and not paying the 280€ are great... No offence, but what would be your incentive to pay the 280€?
Maybe using an escrow would increase your chances of finding somebody to make the purchase?
By the way, i assume you want to buy something legal?
|
|
|
|
|
bitcoin-cli getmempoolinfo
{
"loaded": true,
"size": 7667,
"bytes": 3562620,
"usage": 14209280,
"maxmempool": 50000000,
"mempoolminfee": 0.00089410,
"minrelaytxfee": 0.00001000
}
A 2 sat/vbyte tx probably doesn't even end up in my mempool right now... 2 sat/vbyte is perfectly fine, but at this very moment, it's just not enough...
|
|
|
|
The biggest side effect will be that your odds of dying or have life-long disability's due to a covid infection will drop significantly... Sure, there's a chance you'll develop a blood cloth, but the odds of dying or thrombosis due to covid is much higher (even in healthy humans). It's like putting somebody in front of a table with 2 revolvers on it: one contains 1 bullet out of 6 chambers, the other contains 5 bullets: if you're forced to play russian roulette, which one will you pick? Same with covid: it's going to be around for a while, odds are pretty big you'll get infected sooner or later... You have 2 choices: develop immunity by actually going trough the dissease, which still has a 0.2% mortality rate for my age group (according to https://www.statista.com/statistics/1106372/coronavirus-death-rate-by-age-group-italy/), and we're not talking about the morbidity rate.... Or the second choice is getting a covid shot, which has a 0.0005 chance of getting a blood cloth ( https://www.the-scientist.com/news-opinion/blood-clot-risk-from-covid-19-higher-than-after-vaccines-study-68675). Basically, my odds of dying from covid are 400 times higher than my odds of developing a blood cloth (and there's about a 50/50 chance of dying from a blood cloth). So my actual odds of dying of covid are about 800 times higher than my odds of dying of the vaccin. I like those odds. But kidding aside... My wife got vaccinated about a week ago... She had some flu like symptoms for about a day, and her arm was sore for about 2 days... She's working as a teacher for disabled children, so she got priority for her vaccination. I kind of envy her, if i had the chance of getting vaccinated, i'd take it right away. My grandmother got both polio and whooping cough when she was a kid. She told horror stories... My daugher no longer has to fear of getting paralysed or even dying BECAUSE my country actively vaccinated for a couple generations already. If they didn't these diseases would still exist. I'm not saying that there can be no side effects, i'm just saying you have to look at the big picture: how many people will die because of the vaccin vs how many people will live because of the vaccin. |
|
|
|
Should I re-enter the transaction ID into the accelerator every hour?
No, Once is enough... Now it's just waiting untill viabtc mines a (couple of) blocks. This process can still take a lot of time, but way less than if you'd just wait it out. |
|
|
|
I haven't looked at this problem, but quickly got the raw tx, decoded it and decided to post it here, so others don't have to look it up So, you're trying to spend output 0 of tx: 01000000015e333de8e1f0a0f723c3590a15348347e387f111d2cd57b7f206e536d447f012000000008b483045022048f24d351ac50f038d40290b988589b91f756552bece7316fb1d3b0e05a94b2c02210094e22219eacb3251e96cc77f37ed1c0cf8ef460f235d4472438f9d3d937b99a4014104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ffffffff02d8d6000000000000b48201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c4104b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209ac9bd8d6000000000000b48201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c41047bafaf9f46bdbaa9caddc1071e6c0c438e691246b72b0eb87fde4e6c61634e963d2d513391593016339d649c1f1d44e92316dc72f64fa0d3785bd47f49a1b93cac9b00000000
decoded: {
"txid": "9837a637931f74df1cb52b1045e479e4d7065f72db4d449d732211eb0e5cfd4c",
"hash": "9837a637931f74df1cb52b1045e479e4d7065f72db4d449d732211eb0e5cfd4c",
"version": 1,
"size": 568,
"vsize": 568,
"weight": 2272,
"locktime": 0,
"vin": [
{
"txid": "12f047d436e506f2b757cdd211f187e3478334150a59c323f7a0f0e1e83d335e",
"vout": 0,
"scriptSig": {
"asm": "3045022048f24d351ac50f038d40290b988589b91f756552bece7316fb1d3b0e05a94b2c02210094e22219eacb3251e96cc77f37ed1c0cf8ef460f235d4472438f9d3d937b99a4[ALL] 04d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4",
"hex": "483045022048f24d351ac50f038d40290b988589b91f756552bece7316fb1d3b0e05a94b2c02210094e22219eacb3251e96cc77f37ed1c0cf8ef460f235d4472438f9d3d937b99a4014104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4"
},
"sequence": 4294967295
}
],
"vout": [
{
"value": 0.00055000,
"n": 0,
"scriptPubKey": {
"asm": "OP_SIZE 32 35 OP_WITHIN OP_SWAP OP_SHA256 c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353 OP_EQUAL OP_BOOLAND OP_SWAP 04d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4 OP_CHECKSIGVERIFY OP_SWAP 04b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209 OP_CHECKSIG OP_BOOLOR",
"hex": "8201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c4104b0b1367340a43ce2cc561f93422263a99b03ce0aa76a5d65a03d77fe37b248699df36dd5aad2a5ba174bc245f1f2d0bcce3da3f75cc10d8b3290ba38f86fa209ac9b",
"type": "nonstandard"
}
},
{
"value": 0.00055000,
"n": 1,
"scriptPubKey": {
"asm": "OP_SIZE 32 35 OP_WITHIN OP_SWAP OP_SHA256 c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353 OP_EQUAL OP_BOOLAND OP_SWAP 04d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4 OP_CHECKSIGVERIFY OP_SWAP 047bafaf9f46bdbaa9caddc1071e6c0c438e691246b72b0eb87fde4e6c61634e963d2d513391593016339d649c1f1d44e92316dc72f64fa0d3785bd47f49a1b93c OP_CHECKSIG OP_BOOLOR",
"hex": "8201200123a57ca820c632d997c111049b61669246232c2d735819616e52acc9ee94c414f673e4d353879a7c4104d09be54f7e26f6319c2d366a04f766a7854cda67785c26f5ffdb59d4b9b1f45e272ba7cd09743cbab01fa28d19032e61f35c61ee5298c7dd7301aa05213a4ec4ad7c41047bafaf9f46bdbaa9caddc1071e6c0c438e691246b72b0eb87fde4e6c61634e963d2d513391593016339d649c1f1d44e92316dc72f64fa0d3785bd47f49a1b93cac9b",
"type": "nonstandard"
}
}
]
}
|
|
|
|
|
Show Posts
