Although it seems that you can't easily generate a legacy receive address with the newer Bitcoin core...
It's easy to generate any type of address in the latest version of Bitcoin Core... simply use the getnewaddress command in Bitcoin Core and use the "legacy" option for address_type getnewaddress ( "label" "address_type" )
Returns a new Bitcoin address for receiving payments.
If 'label' is specified, it is added to the address book
so payments received with the address will be associated with 'label'.
Arguments:
1. label (string, optional, default="") The label name for the address to be linked to. It can also be set to the empty string "" to represent the default label. The label does not need to exist, it will be created if there is no label by the given name.
2. address_type (string, optional, default=set by -addresstype) The address type to use. Options are "legacy", "p2sh-segwit", and "bech32".
Result:
"str" (string) The new bitcoin address
Note that to provide the 2nd option (address_type), you must provide the 1st option (label), but it can be empty... so you can use: getnewaddress "" "legacy"
And lastly, you can also set the "default" address type that Bitcoin Core will generate by using the -addresstype commandline parameter (or setting it in bitcoin.conf). |
|
|
|
Also where is the link that shows which email addresses are compromised? Is it if you receive spam email from it... then yes? But someone also said real name and addresses were also shown... how do you know if you are on that list or not? Obviously there isn't a public document that shows this right? But is there anything that says okay if your email is shown here... then your real name and address is also exposed? You can search here: https://www.argent.xyz/ledgerhack/I've tested it using emails from the leaked lists that were available on Github for a while before it was taken down... it seems to be reporting the data from those lists "correctly" and will advise if your email was in the "email only" list or the "full details" list. |
|
|
|
Have a read through some of the breaches listed here: https://en.wikipedia.org/wiki/Data_breachThere are plenty of big name companies that have leaked all sorts of information (like full personal details and/or banking details etc) that are still operating... and a lot of those data breaches made headline news in mainstream media etc. This breach is a big deal in the "cryptosphere"... but I haven't seen mention of it anywhere outside of cryptocurrency related websites. I don't know if this incident will cause Ledger to go bankrupt... consider if each of those 272,000 affected only paid ~$70 for a single Nano S... that's ~$19million... I don't see the manufacturing costs of the devices, wages/salaries nor the R&D costs being anywhere near that... And that's not even counting the customers who aren't included in the breach.  Their reputation has taken a, deservedly, massive hit... they'll need to work hard to regain that trust. |
|
|
|
When I do this, it gives me a long btc address that stars with the number 3. Then you check it on nano ledger s to see if the address is correct... then you click approve right? The thing is when i disconnected my nano ledger s and did this again to repeat this... it would show the same address that starts with the number 3. Does that mean this is the default btc receiving address for my nano ledger s?
When you setup your "accounts" in Ledger Live... it receives a copy of your "Master Public Key" from the device. This allows Ledger Live to derive all your receiving addresses, even when the device is not connected!Technically, you only need to the device connected if you want to do address confirmation on the device screen to ensure that your Ledger Live has not been compromised and is not generating "fake" addresses to steal your funds. This is HIGHLY recommended. However... the address shown is NOT your "default" receive address... it is just the first receiving address that has currently not received any funds. Once that address receives some funds, it will be marked as "used" by Ledger Live and next time you click "Receive" tab, it'll give you the next unused receive address. The other thing is this. I just googled native segwit and segwit and it seems more ppl say native segwit is better because of cheaper fees is that true? So could i later on... go from segwit to native segwit? Or would you not recommend it? A transaction using "Native SegWit" inputs, results in a transaction with a smaller transaction "size"... than a transaction that has the same number of Legacy or "Nested" SegWit inputs. This allows one of 2 things: 1) You save on fees, as the same fee rate with a smaller transaction size obviously results in a smaller total transaction fee paid: ie. possible example: 10 input Legacy transaction = 2000 bytes 10 input NestedSegwit Transaction = 1000 bytes 10 input NativeSegwit Transaction = 750 bytes If all 3 paid the fee rate of 10 sats/byte... it's obvious why Native Segwit pays a smaller total fee 2) A less obvious result, is that you could potentially get your transaction confirmed "faster"... by paying a higher fee rate, that results in the same total fee... ie. possible example: 10 input Legacy transaction = 2000 bytes 10 input NestedSegwit Transaction = 1000 bytes 10 input NativeSegwit Transaction = 750 bytes If the Legacy transaction was set at 10 sats/byte, the total fee paid would be 20,000 sats... but as the Native Segwit one is only 750 bytes, if you paid 20,000 sats total fee... your effective fee rate would have to be: 26.6 sats/byte!!?!  This would obviously be a higher priority transaction for the miners  As for whether you should use "Nested" or "Native" segwit... I'd say that if the services/websites you use support "native" segwit, then I'd recommend you use that. If you use some that don't support the "bc1" native addresses, stick with the "Nested" ("3"-type) account in Ledger Live. It honestly, doesn't really matter which one you use... they're both "better" than Legacy addresses  |
|
|
|
Also... if you look at it from this way, at what price exactly did you receive the btc at? Because the amount of btc they sent to you at the time even though it shows 0 confirmations... well it will always get confirmed right? Or there could be an issue like i heard about double spending a while back? I assume you would calculate the price you received it at ... the moment you receive 3 confirmations or when the USD amount no longer change?
You don't receive btc at a fiat price... you receive a given amount of BTC...  What value you assign to that BTC is up to you. The "price" is so volatile and varies across countries, exchanges, services etc... there is no definitive "This is the current value of BTC in <insert currency here>" value. Explorers like blockchain.com that show a fiat value on transactions simply take a snapshot of the exchange price from some source (likely an exchange API) at the time the block is first mined. Also could you send any btc from your wallet if the btc you received did not have confirmations or enough confirmations?
If your wallet allows spending "unconfirmed coins"... some wallets do, some wallets don't... Electrum has a specific setting:  Bitcoin Core has a setting specifically for change amounts generated ... but I'm fairly sure will allow you to spend unconfirmed coins that were "received" regardless of that setting:  |
|
|
|
I am using mobile and bither generates address starting with 1 as well, but its different from my address.
Can you suggest another site or tool which generates legacy address from private key. Also, for my information, how many addresses can be generated from 1 private key?
You're right, I tried downloading Bither and importing a private key and it asked whether I wanted to use "compressed" or "compressed"... So, you didn't see your address as either option on the "select compressed or uncompressed key" screen?   Does the private key you have start with a "5", "L" or "K"? |
|
|
|
I'm getting same error "transaction creation failed."
I last opened core in 2012.
I am able to dump privkey of my address that has btc, but when I import it to bither, it shows some other address.
Am I missing something?
If it's from 2012, no doubt your Bitcoin Core address starts with a "1"... and I'm guessing the address in "bither" starts with either a "3" or "bc1"... - The "1"-type address is a "Legacy" address - The "3" and "bc1"-type addresses are "SegWit" addresses. If this is what is happening, you should use a wallet that supports importing private keys and creating legacy addresses... are you using a desktop or mobile device? |
|
|
|
If you really want to test your strategy you could play at crypto.games and use play money. This gave me an idea of how the bot works, also in programmer mode, without risking my real coins.
I hope it can work for you too.
That's actually a really good idea, and what I generally do with most of my scripts... test them with the "PLAY" currency on cryptogames... The only issue is that the minimum bet values (and current balances) are generally quite different for each currency So I use an "if-then-else" at the top of the script that determines which currency is currently selected, and automatically adjusts the basebet amount and other variables as required. Something like this: ...
if currency == "btc" then
-- CHANGE THESE ACCORDING TO YOUR BALANCE
baseBet = 0.00000001
target = 0.01170333
maxLossStreak = 20
elseif currency == "doge" then
-- CHANGE THESE ACCORDING TO YOUR BALANCE
baseBet = 1
target = 300000
maxLossStreak = 60
elseif currency == "play" then
-- CHANGE THESE ACCORDING TO YOUR BALANCE
baseBet = 100
target = 30000000
maxLossStreak = 90
else
print("no basebet set for this currency [" .. currency .. "]!!! -- STOPPING!")
stop()
end
...
|
|
|
|
Yeah... they were the ones I was thinking of... As I recall, they are different for each network type (main, test, regtest etc). I think I set my "mainnet" ones to be the same (or similar) values as the regtest ones and then it starting syncing better. Glad you managed to get it sorted |
|
|
|
I vaguely remember tweaking something regarding blockchain and/or chainstate "size" in one of the "chainparams" source code files... I'm not sure if that actually has anything to do with whether or not it requires a certain number of blocks before syncing... Really beginning to wish I had kept my modifications now |
|
|
|
It makes me mad how its all being handled!
So here is a question then... aside from being able to change history and/or inventing time travel to be able to prevent the leak from happening in the first place, what should Ledger have done differently after the leak was discovered? What should they be doing now that they aren't already? I suspect that there is (realistically) nothing they can do at this point that would make anyone happy... the data is out, you can't delete things from the internet. |
|
|
|
Can someone actually tell me if the bots actually give the user an edge over other people who do not use this bot? I know strategies like Martingale does not work on most sites offering "Dice" games, but does this bot give you other strategies that gives you the advantage?
Essentially it just allows you to automate all sorts of weird and wonderful things that you can't really do using the normal settings on websites... you can try all sorts of stupid things "strategies"... you just click "Go" and it'll happily lose your money "run your strategy" while you watch the fun graph Anyone claiming to have a "guaranteed" winning script is either stupid or a scammer... especially if they want to charge you money for it I downloaded the latest version and I tried it on Stake, but I do not see anything different to my normal wins/losses? (Or do you apply your own strategies for success?) That is to be expected... using the bot does not alter the "house edge" in any way, so the wins/losses should be "similar" to what you would get using the web interface. |
|
|
|
I define PC#1 as the one that mined the 6 blocks. PC#2 is the other one. Note that it took many hours to mine them. I don't like calling it luck, since it's possibilities, but I must have been unlucky.
That's why I spent a bit of time getting cpuminer/bfgminer up and running... it was quite a hassle getting one to work properly, but it definitely had a better hash rate than using generatetoaddress. 2020-12-23T12:47:03Z Synchronizing blockheaders, height: 6 (~22.22%)
Indeed, it seems to be syncing the block headers at least, so that's a good sign that it is connecting properly... for some reason it seems to think that 6 is only ~22% of the being synced... so you might need to generate "a few" more blocks for it consider the headers synced and to start collecting blocks? I don't have a bitcoin.conf file on my PC#2. Should I?
Probably not necessary if it is connected and showing as a peer etc... |
|
|
|
From memory, it took a few blocks for the 2nd instance (was running in a VM), to decide that that was the longest chain and to start syncing the blocks... like I said, I deleted everything, so I can't test it now  When a block is mined on PC#1, do you see any of the "UpdateTip" type messages appear in the debug.log on PC#2? Also, what are your settings on PC#2? ie. contents of bitcoin.conf etc |
|
|
|
Not defending Ledger, but every business that asks for your information flows through an API. I'm a software engineer, an API to serve customer data is industry standard. But the industry standard is to secure your API. Ledger probably had poor security hygiene practices internally, which led to this.
As far as I can tell, they're claiming that it was a third-party service responsible for marketing, some outfit named "Iterable"... Who is the third party solution? Why were they processing customers’ data?
Ledger e-commerce and marketing teams use a third-party solution (Iterable) to send and analyze transactional and marketing emails to customers who have bought products on ledger.com or have signed up to receive our newsletters.
So, it would seem that Ledger did not have enough oversight on how their partners were setting up/connecting to their systems to retrieve customer data... and Iterable fucked up when configuring their API access. No doubt, the only winners in all of this will be lawyers while they argue about who is actually at fault while charging $$$/hr... and the scammers who manage to trap the unwary with their phishing emails/txts/phone calls... |
|
|
|
Looking at the screenshot... you still have 0.00622436 BTC (~6.22436mBTC) remaining in the wallet after the "unconfirmed transaction". You should, theoretically, be able to use this, along with the change from the "unconfirmed transaction" in a "Child Pays For Parent" transaction. However, based on the info from your previous posts, due to your wallet using Legacy addresses, the total size, across both the unconfirmed and the CPFP transactions, would be at least 4100 bytes... at a rate of 100 sats/byte (which should hopefully get a confirmation within a few hours), you would be paying a total fee of ~0.00410000 BTC in fees!!?! You could "gamble" and try using 50 sats/byte (currently around 4-5 blocks from the Tip) and mark the CPFP transaction as "RBF enabled"... that way if it is still taking too long, you could bump the fee later. This case is the perfect illustration of: 1. Why users should seriously consider moving to SegWit (to reduce total transaction sizes and therefore reduce total fees) and 2. Why users should consolidate UTXOs in their wallets when fees are at low levels. ie. Only using 1 or 2 legacy inputs to a transaction (instead of 26!!?! ), drastically reduces the overall transaction size, which drastically reduces the total fees required. |
|
|
|
possibly... or "transaction" information etc... So, the 2nd PC is stuck on 'zero' blocks in the "information" screen? |
|
|
|
4-but at the bottom appear a green line with ACTIVE COIN CHECK and it not allow to go head.
If you mean this:  It is just, as ranochigo said, highlighting the fact that you are manually selecting a "subset" of the coins available to spend... In my testnet wallet shown, I have selected only 1 UTXO (out of 46 total available) in my wallet... Normally, you don't need to goto the "Coins" tab, select a coin, right click and select spend... you only do that if you want full control over exactly with coins get spent from your wallet (aka "coin control"). Instead, you should just use the "Send" tab... enter the address you want to send to, enter the amount you want to send and click "Pay" NOTE: as ranochigo pointed out, it seems like you have created a 2FA wallet... the first time you try to spend from a 2FA wallet, it will "auto buy" credits, as 2FA wallets have an additional service fee that is charged by TrustedCoin. Read this, especially the "How much does it cost?" section: https://api.trustedcoin.com/#/electrum-helpIf you don't want to pay the fees, I recommend that you restore the wallet, enter the seed and when prompted, select "disable 2FA"... then create a new "standard" wallet, and move your coins to that wallet! |
|
|
|
If I'm not wrong this means the fees is around 920$  as it gives me error message "max fee exceeded" when I press OK You are wrong... your Electrum is set to mBTC... ie. milliBTC... the fee being shown is 0.0803 mBTC = 0.00008030 BTC... or around US$2 Also, you're most likely getting the weird "max fee exceeded" error message because you simply don't have enough balance in your wallet to be creating the CPFP payment... hence why it is showing a negative(!!?! ) output amount of -0.02195 mBTC... you can't generate a negative amount! To avoid confusion in the future, you might want to go into the Electrum settings and change the base Unit to "BTC" ("Tools" -> "Preferences" -> "General" -> "Base Unit") At this point in time, I don't think there is anything you can do to push this payment through... it's just going to have to wait until the mempool empties out and 1 sat/byte transactions start getting include in blocks. This could, potentially, take days. Perhaps over the Christmas holiday period while people are "busy" with family and real world stuff etc, it might clear out. |
|
|
|
|
Show Posts
