Search content
Sort by
Showing 20 of 22 results by angelo1oc
On this BIP, there are 2 ways of creating threshold signatures, depending on the number of “k” (minimum signatures for approval)
Let’s say that K=16, then we use “OP_16” which is equal to 0x60
If K=17 what number should we use? Is it 0x61=97 or 0x11=17?
Because k is 17
Thanks
angelo
Code:
The output script produced also depends on the value of k. If k is less than or equal to 16:
KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL
if k is greater than 16:
KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD k OP_NUMEQUAL
KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD OP_k OP_NUMEQUAL
if k is greater than 16:
KEY_1 OP_CHECKSIG KEY_2 OP_CHECKSIGADD ... KEY_n OP_CHECKSIGADD k OP_NUMEQUAL
Let’s say that K=16, then we use “OP_16” which is equal to 0x60
If K=17 what number should we use? Is it 0x61=97 or 0x11=17?
Because k is 17
Thanks
angelo
Or just concurrently sign multiple versions, and the last signer/proposer only completes and announces the one matching the signing set.
The same mechanism can be used to sign for multiple fee rates since it can be useful to fee-bump without having to revisit all the signers.
That said, unless it's necessary for accountability to disclose which signer set signed, you construct a key distribution such that any of the 3-of-5 sets can sign the root directly-- which would minimize fees generally.
The same mechanism can be used to sign for multiple fee rates since it can be useful to fee-bump without having to revisit all the signers.
That said, unless it's necessary for accountability to disclose which signer set signed, you construct a key distribution such that any of the 3-of-5 sets can sign the root directly-- which would minimize fees generally.
On the third point, you are saying to have a "standard" 3 of 5 MuSig1, the only problem is that you are disclosing "all" the members of the group (signers).
As for the first item, it make sense :-) it didn't occur to me, but is doable, the only drawback would be the amount of information I would need to transfer into the PBST (custom), specially on cases with more than 5 participants. As a matter of fact, I would probably need one PSBT per combination fee. Interesting..
Thanks for your thoughts
angelo
⭐ Merited by ABCbits (1)
Hi I have a question related fees ( basically Virtual Size):
When I use let's say 3-of-5 signatures embedded on a Huffman tree composed on 3-of-3, and assuming we have only one input transaction and one output transaction, the first user to sign will need to decide the "transaction fee", in the software I run a "simulation" were I "sign" all the branches, so I end with the following values for the Virtual Size:
[203,203,203,203,211,211].
If instead I'm doing a 5-of-10, this is the list of virtual sizes:
[252,293,325,349,373,381,413,445,469,493,501,525,549,573,581,597,621,629,645,653,669,693,725,749,773,781,805,829,853,861,877,901,909,925,933,949,965,989,1013,1021,1037,1061,1069,1085,1093,1109,1117,1141,1149,1165,1173,1189,1197,1205,1221,1229,1253,1285,1309,1333,1341,1365,1389,1413,1421,1437,1461,1469,1485,1493,1509,1525,1549,1573,1581,1597,1621,1629,1645,1653,1669,1677,1701,1709,1725,1733,1749,1757,1765,1781,1789,1805,1829,1853,1861,1877,1901,1909,1925,1933,1949,1957,1981,1989,2005,2013,2029,2037,2045,2061,2069,2077,2101,2109,2125,2133,2149,2157,2165,2181,2189,2197,2205,2221,2229,2237]
Since the first user needs to decide the transaction fee, we are suggesting the user to use the "biggest" values, for a 3-of-5 would be 211, for a 5-of-10 would be 2237, since we don't know how from the rest of the users how is signing.
My question is, is this correct? I'm I correct in suggesting the higher values?
Because the alternative would be any posible value, but if turn out that the final combinations has a Virtual Size equal to the biggest one, then the transaction will never commit to the node.
Regards
angelo
When I use let's say 3-of-5 signatures embedded on a Huffman tree composed on 3-of-3, and assuming we have only one input transaction and one output transaction, the first user to sign will need to decide the "transaction fee", in the software I run a "simulation" were I "sign" all the branches, so I end with the following values for the Virtual Size:
[203,203,203,203,211,211].
If instead I'm doing a 5-of-10, this is the list of virtual sizes:
[252,293,325,349,373,381,413,445,469,493,501,525,549,573,581,597,621,629,645,653,669,693,725,749,773,781,805,829,853,861,877,901,909,925,933,949,965,989,1013,1021,1037,1061,1069,1085,1093,1109,1117,1141,1149,1165,1173,1189,1197,1205,1221,1229,1253,1285,1309,1333,1341,1365,1389,1413,1421,1437,1461,1469,1485,1493,1509,1525,1549,1573,1581,1597,1621,1629,1645,1653,1669,1677,1701,1709,1725,1733,1749,1757,1765,1781,1789,1805,1829,1853,1861,1877,1901,1909,1925,1933,1949,1957,1981,1989,2005,2013,2029,2037,2045,2061,2069,2077,2101,2109,2125,2133,2149,2157,2165,2181,2189,2197,2205,2221,2229,2237]
Since the first user needs to decide the transaction fee, we are suggesting the user to use the "biggest" values, for a 3-of-5 would be 211, for a 5-of-10 would be 2237, since we don't know how from the rest of the users how is signing.
My question is, is this correct? I'm I correct in suggesting the higher values?
Because the alternative would be any posible value, but if turn out that the final combinations has a Virtual Size equal to the biggest one, then the transaction will never commit to the node.
Regards
angelo
It just happed I've recently launch this wallet.
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
Here you can see true Taproot K of N multisig.
You can test it on TestNet
I use Multy spending paths (address and script) with Huffman TapTrees, so you could have a 2 of 100 multisg and pay very little of transaction fee and only reveals the 2 public keys of the 2 signatures, the other 96 address are NEVER revealed.
:-)
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
Here you can see true Taproot K of N multisig.
You can test it on TestNet
I use Multy spending paths (address and script) with Huffman TapTrees, so you could have a 2 of 100 multisg and pay very little of transaction fee and only reveals the 2 public keys of the 2 signatures, the other 96 address are NEVER revealed.
:-)
It just happed I've recently launch this wallet.
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
Here you can see true Taproot K of N multisig.
You can test it on TestNet
I use Multy spending paths (address and script) with Huffman TapTrees, so you could have a 2 of 100 multisg and pay very little of transaction fee and only reveals the 2 public keys of the 2 signatures, the other 96 address are NEVER revealed.
:-)
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
Here you can see true Taproot K of N multisig.
You can test it on TestNet
I use Multy spending paths (address and script) with Huffman TapTrees, so you could have a 2 of 100 multisg and pay very little of transaction fee and only reveals the 2 public keys of the 2 signatures, the other 96 address are NEVER revealed.
:-)
Sorry for the confusion.
Here's the link to the source code:
https://github.com/angelonardone/DistributedCryptography
What I mean with "Desktop" is that is NOT for mobile devices, it work on Windows, Mac, Linux, and as a WebServer app as well.
The default Key Derivation follows the BIP 86 standard.
In addition I've created Multisignature schema of K of N using Huffman TapTrees and Multyspending paths (address and scripts)
And it is a "real" wallet, it happens that I just release it yesterday and I'm looking for feedback in order to improve it.
Regards
~angelo
Here's the link to the source code:
https://github.com/angelonardone/DistributedCryptography
What I mean with "Desktop" is that is NOT for mobile devices, it work on Windows, Mac, Linux, and as a WebServer app as well.
The default Key Derivation follows the BIP 86 standard.
In addition I've created Multisignature schema of K of N using Huffman TapTrees and Multyspending paths (address and scripts)
And it is a "real" wallet, it happens that I just release it yesterday and I'm looking for feedback in order to improve it.
Regards
~angelo
Re: New Desktop Wallet - I’d Really Appreciate Your Feedback!
Hi Cricktor,
Thanks for your feedback.
As for point 1, I’ll definitely going to look into it. I actually thought about it, in particular signing the HASH of the version with a PublicKey associated to an address on the blockchain which I hold, but ultimately decided on this first public version to go for something easier, but I’ll look into the project I’ve mentioned and see if it’s easier to implement and brings more guarantees.
In regards to the “browser” issues, you are correct, but this can be mitigated by the user with their choice of browser (an IOS, let’s say “tails”). I could eventually bake a browser into the code. As for the webserver I use Kestrel, which is an open source (https://github.com/dotnet/aspnetcore).
In regards to your third point, about the structure of the code (and the libraries I use), you are also correct, they are not on a “standard” project build tree, but there is a reason for it.
To develop the wallet I use a programing language called GeneXus (genexus.com) which I’ve been using for over 25 years. With it I’ve developed solutions currently used by hundreds of thousand of users on multiple industries, like education and pharmaceutical manufacturing, It’s a fantastic tool to build mission critical business application, the only problem is that is a “paid” development tool and it is not really open-source friendly, but at the end of the day, it “generates” C# code, which as you pointed out, is not standard, and is difficult to read, but the code it still there, everything the app does is in the source and with a little bit of effort anybody “fluent” on C# can understand what is doing and analyze the critical points (how the keys, encryption and communication is handled), and if you follow the instructions on the wiki you can build it yourselfer and use that version.
“pooya87”, made a point about the libraries that are include in the project, those libraries are generated by GeneXus, but that part is open-source, and here’s the link to them:
https://github.com/genexuslabs/DotNetClasses
I also use some other open-source libraries:
• NBitcoin (https://github.com/MetacoSA/NBitcoin)
• SecretSharingDotNet (https://github.com/shinji-san/SecretSharingDotNet)
• GoogleAuthenticator (https://github.com/BrandonPotter/GoogleAuthenticator)
• QRCoder (https://github.com/codebude/QRCoder)
Does this make sense?
I’m trying to be as transparent as possible with the tools I have :-)
Thanks again.
Thanks for your feedback.
As for point 1, I’ll definitely going to look into it. I actually thought about it, in particular signing the HASH of the version with a PublicKey associated to an address on the blockchain which I hold, but ultimately decided on this first public version to go for something easier, but I’ll look into the project I’ve mentioned and see if it’s easier to implement and brings more guarantees.
In regards to the “browser” issues, you are correct, but this can be mitigated by the user with their choice of browser (an IOS, let’s say “tails”). I could eventually bake a browser into the code. As for the webserver I use Kestrel, which is an open source (https://github.com/dotnet/aspnetcore).
In regards to your third point, about the structure of the code (and the libraries I use), you are also correct, they are not on a “standard” project build tree, but there is a reason for it.
To develop the wallet I use a programing language called GeneXus (genexus.com) which I’ve been using for over 25 years. With it I’ve developed solutions currently used by hundreds of thousand of users on multiple industries, like education and pharmaceutical manufacturing, It’s a fantastic tool to build mission critical business application, the only problem is that is a “paid” development tool and it is not really open-source friendly, but at the end of the day, it “generates” C# code, which as you pointed out, is not standard, and is difficult to read, but the code it still there, everything the app does is in the source and with a little bit of effort anybody “fluent” on C# can understand what is doing and analyze the critical points (how the keys, encryption and communication is handled), and if you follow the instructions on the wiki you can build it yourselfer and use that version.
“pooya87”, made a point about the libraries that are include in the project, those libraries are generated by GeneXus, but that part is open-source, and here’s the link to them:
https://github.com/genexuslabs/DotNetClasses
I also use some other open-source libraries:
• NBitcoin (https://github.com/MetacoSA/NBitcoin)
• SecretSharingDotNet (https://github.com/shinji-san/SecretSharingDotNet)
• GoogleAuthenticator (https://github.com/BrandonPotter/GoogleAuthenticator)
• QRCoder (https://github.com/codebude/QRCoder)
Does this make sense?
I’m trying to be as transparent as possible with the tools I have :-)
Thanks again.
Re: New Desktop Wallet - I’d Really Appreciate Your Feedback!
I understand what you mean.
You can build it yourself, the GitHub repository is on the Wiki, along with a step by step process on how to build it.
In regards to your second point.
I've designed it to be completely offline (the taproot wallet), but for the "group" functionalities you need to be connected to the internet.
All the communication with the server for this "group" functionalities are AES256 encrypted, more over, all the data in the server is encrypted by the user's internal PrivateKeys, so there is no way to access any of the information hosted on the servers.
I haven't been able to finish the Wiki yet, but all of this will be explained in detail.
But you can now test all the functionalities (after you build it from the "source" :-) ) on testnet.
In addition I'll be publishing extensive automated test results once I've finish created and running them.
At this point I don't think I can "guarantee" more than these.
You have to test it for yourself.
Does it make sense what i'm saying?
Thanks for your question.
~angelo
You can build it yourself, the GitHub repository is on the Wiki, along with a step by step process on how to build it.
In regards to your second point.
I've designed it to be completely offline (the taproot wallet), but for the "group" functionalities you need to be connected to the internet.
All the communication with the server for this "group" functionalities are AES256 encrypted, more over, all the data in the server is encrypted by the user's internal PrivateKeys, so there is no way to access any of the information hosted on the servers.
I haven't been able to finish the Wiki yet, but all of this will be explained in detail.
But you can now test all the functionalities (after you build it from the "source" :-) ) on testnet.
In addition I'll be publishing extensive automated test results once I've finish created and running them.
At this point I don't think I can "guarantee" more than these.
You have to test it for yourself.
Does it make sense what i'm saying?
Thanks for your question.
~angelo
⭐ Merited by JayJuanGee (1)
I just release a beta version of a FULL taproot wallet for Desktops, here are the specs:
The wallet support the following Bitcoin standards:
• Brain Wallets (not recommended).
• Wallet Import Format (WIF) for legacy individual keys.
• Hierarchical Deterministic Wallets (BIP 32).
• Mnemonic code for generating deterministic keys (BIP 39).
• Multi-Account Hierarchy for Deterministic Wallets - Legacy Format of HD (BIP 44)
• Derivation scheme for P2WPKH-nested-in-P2SH based accounts (BIP 49)
• Derivation scheme for P2WPKH based accounts (BIP 84)
• Segregated Witness (BIP 141), (BIP 143) and (BIP 144)
• Bech32 segwit address implementation with error detection (BIP 163)
• Key Derivation for Single Key P2TR Outputs (BIP 86) ~ our default mode
• Validation of Taproot Scripts (BIP 341 and BIP 342)
• Electrum protocol compatible
• Multy spending paths (address and script)
• K of N multisignature (using Huffman TapTrees)
And here a like to the wiki where you can download it and test it.
https://wiki.distributedcryptography.com/wiki.aspx?9,Toc%3aOur+application,
I've build some advance functionalities not seen anywhere, here are links to some docs and videos:
In this link I explain (and have a video) on how the Concensus Backup works:
https://wiki.distributedcryptography.com/wiki.aspx?1048,Consensus+Backup
On the following one about the Delegated Multisignature”:
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
regards
~angelo
The wallet support the following Bitcoin standards:
• Brain Wallets (not recommended).
• Wallet Import Format (WIF) for legacy individual keys.
• Hierarchical Deterministic Wallets (BIP 32).
• Mnemonic code for generating deterministic keys (BIP 39).
• Multi-Account Hierarchy for Deterministic Wallets - Legacy Format of HD (BIP 44)
• Derivation scheme for P2WPKH-nested-in-P2SH based accounts (BIP 49)
• Derivation scheme for P2WPKH based accounts (BIP 84)
• Segregated Witness (BIP 141), (BIP 143) and (BIP 144)
• Bech32 segwit address implementation with error detection (BIP 163)
• Key Derivation for Single Key P2TR Outputs (BIP 86) ~ our default mode
• Validation of Taproot Scripts (BIP 341 and BIP 342)
• Electrum protocol compatible
• Multy spending paths (address and script)
• K of N multisignature (using Huffman TapTrees)
And here a like to the wiki where you can download it and test it.
https://wiki.distributedcryptography.com/wiki.aspx?9,Toc%3aOur+application,
I've build some advance functionalities not seen anywhere, here are links to some docs and videos:
In this link I explain (and have a video) on how the Concensus Backup works:
https://wiki.distributedcryptography.com/wiki.aspx?1048,Consensus+Backup
On the following one about the Delegated Multisignature”:
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
regards
~angelo
I’m relatively new to Bitcoin; my journey started in 2021 after listening to a Lex Fridman podcast featuring Robert Breedlove. That episode sent me down a rabbit hole (I’m sure many of you can relate), and I’ve since decided to contribute to the community. For the past two years, I’ve been developing a Desktop Wallet.
Coming from a background in business application software development, I’ve focused on usability and innovative features that could make it more accessible to “non-techies.”
Two of the main “new” features I’ve worked on are:
• Consensus Backup
• Delegated Multisignature
I’ve dedicated all my free time over the last two years to this project, and I’d really appreciate your honest feedback. Am I on the right track, or have I missed the mark?
Your insights would mean a lot to me. Thank you in advance for your time and help.
~angelo
In this link I explain (and have a video) on how the Concensus Backup works:
https://wiki.distributedcryptography.com/wiki.aspx?1048,Consensus+Backup
On the following one about the Delegated Multisignature”:
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
I’ve included many more features focus on security that I haven’t been able to post on the wiki yet, but are available on the actual application, if you want to try it
The wallet support the following Bitcoin standards:
• Brain Wallets (not recommended).
• Wallet Import Format (WIF) for legacy individual keys.
• Hierarchical Deterministic Wallets (BIP 32).
• Mnemonic code for generating deterministic keys (BIP 39).
• Multi-Account Hierarchy for Deterministic Wallets - Legacy Format of HD (BIP 44)
• Derivation scheme for P2WPKH-nested-in-P2SH based accounts (BIP 49)
• Derivation scheme for P2WPKH based accounts (BIP 84)
• Segregated Witness (BIP 141), (BIP 143) and (BIP 144)
• Bech32 segwit address implementation with error detection (BIP 163)
• Key Derivation for Single Key P2TR Outputs (BIP 86) ~ our default mode
• Validation of Taproot Scripts (BIP 341 and BIP 342)
• Electrum protocol compatible
• Multy spending paths (address and script)
• K of N multisignature (using Huffman TapTrees)
Coming from a background in business application software development, I’ve focused on usability and innovative features that could make it more accessible to “non-techies.”
Two of the main “new” features I’ve worked on are:
• Consensus Backup
• Delegated Multisignature
I’ve dedicated all my free time over the last two years to this project, and I’d really appreciate your honest feedback. Am I on the right track, or have I missed the mark?
Your insights would mean a lot to me. Thank you in advance for your time and help.
~angelo
In this link I explain (and have a video) on how the Concensus Backup works:
https://wiki.distributedcryptography.com/wiki.aspx?1048,Consensus+Backup
On the following one about the Delegated Multisignature”:
https://wiki.distributedcryptography.com/wiki.aspx?1049,Delegated+Multisignature
I’ve included many more features focus on security that I haven’t been able to post on the wiki yet, but are available on the actual application, if you want to try it
The wallet support the following Bitcoin standards:
• Brain Wallets (not recommended).
• Wallet Import Format (WIF) for legacy individual keys.
• Hierarchical Deterministic Wallets (BIP 32).
• Mnemonic code for generating deterministic keys (BIP 39).
• Multi-Account Hierarchy for Deterministic Wallets - Legacy Format of HD (BIP 44)
• Derivation scheme for P2WPKH-nested-in-P2SH based accounts (BIP 49)
• Derivation scheme for P2WPKH based accounts (BIP 84)
• Segregated Witness (BIP 141), (BIP 143) and (BIP 144)
• Bech32 segwit address implementation with error detection (BIP 163)
• Key Derivation for Single Key P2TR Outputs (BIP 86) ~ our default mode
• Validation of Taproot Scripts (BIP 341 and BIP 342)
• Electrum protocol compatible
• Multy spending paths (address and script)
• K of N multisignature (using Huffman TapTrees)
What order should I follow when creating a transaction
Is there any standard or recommendation on how to join coins in order to send a particular amount?
Do you add base on oldest to newest? (or viceversa)
Do you add them based on amount, meaning lowest to highest (or viceversa)?
Do you randomly pick until you add-up enough for the total to send?
Thanks
angelo
Is there any standard or recommendation on how to join coins in order to send a particular amount?
Do you add base on oldest to newest? (or viceversa)
Do you add them based on amount, meaning lowest to highest (or viceversa)?
Do you randomly pick until you add-up enough for the total to send?
Thanks
angelo
Re: funds immediately leaving electron wallet after receiving from TestNet faucet
Merit?
What do you mean?
No, I have over 30 years of experience developing software, it just I just started with blockchain, and the only way I know to learn it's just by doing.
this is why I'm doing the wallet from scratch (almost, I'm using the NBitcoin library, but I'm planning to replace it as soon as I have a stable wallet)
What do you mean?
No, I have over 30 years of experience developing software, it just I just started with blockchain, and the only way I know to learn it's just by doing.
this is why I'm doing the wallet from scratch (almost, I'm using the NBitcoin library, but I'm planning to replace it as soon as I have a stable wallet)
Re: funds immediately leaving electron wallet after receiving from TestNet faucet
I think I've figured out the problem and it's not what you think :-)
let me give you a little bit of background:
In order to crate a this particular wallet I was using "Brain wallets" (which is basically a sha-256 of a text), but I was using simple words like "black" and "white".
I think this simple "words" are part of a databases of "simple" KEYS, which could be easily generated from any source of "public common passwords".
What I think happened is that somebody is "scanning" the "memory pool" of the block chain for any money going to those addresses and immediately run a Vin on those, and they are using the TestNetwork to "test it" :-)
In order to test this "theory" this time I've created a trully random KEY and copy and pasted into the Electron wallet (via WIF) and nothin happened.
I appreciate the comments,
For those that asked for the link to the source code I didn't poste them because it's currently connecting to a "Bitcoin Explorer" that i'm developing (in conjunction with the wallet) an is in my internal network.
As soon as it's stable enough I plan to put it public
Thanks again for all the support.
Grate community !!
let me give you a little bit of background:
In order to crate a this particular wallet I was using "Brain wallets" (which is basically a sha-256 of a text), but I was using simple words like "black" and "white".
I think this simple "words" are part of a databases of "simple" KEYS, which could be easily generated from any source of "public common passwords".
What I think happened is that somebody is "scanning" the "memory pool" of the block chain for any money going to those addresses and immediately run a Vin on those, and they are using the TestNetwork to "test it" :-)
In order to test this "theory" this time I've created a trully random KEY and copy and pasted into the Electron wallet (via WIF) and nothin happened.
I appreciate the comments,
For those that asked for the link to the source code I didn't poste them because it's currently connecting to a "Bitcoin Explorer" that i'm developing (in conjunction with the wallet) an is in my internal network.
As soon as it's stable enough I plan to put it public
Thanks again for all the support.
Grate community !!
Re: funds immediately leaving electron wallet after receiving from TestNet faucet
First of all I really appreciate all the feedback and responses.
This is what I'll try next in order to rule out any posible compromised software/hardware.
1- I'll reinstall a fresh copy of iOS on an old mac laptop that I happened to have
2- download from Microsoft .NET dev kit.
3 - post the source code of my wallet on GitHub
4 - download on the "fresh" computer the code from GitHub
5 - compile, run and create a new "one address wallet"
6 - request some test coins.
7 - examine result.
Am I missing something with this procedure?
Could this be compromise in any way?
This will take me some time but I'll post my results as soon as I have them
Thanks
This is what I'll try next in order to rule out any posible compromised software/hardware.
1- I'll reinstall a fresh copy of iOS on an old mac laptop that I happened to have
2- download from Microsoft .NET dev kit.
3 - post the source code of my wallet on GitHub
4 - download on the "fresh" computer the code from GitHub
5 - compile, run and create a new "one address wallet"
6 - request some test coins.
7 - examine result.
Am I missing something with this procedure?
Could this be compromise in any way?
This will take me some time but I'll post my results as soon as I have them
Thanks
Re: funds immediately leaving electron wallet after receiving from TestNet faucet
This is getting stranger by the minute.
I've created another public KEY, this time I didn't even look at the prive key.
i've created on the wallet that I'm developing using NBitcoin library.
I'm compiling everything from source code
Then I requested to a couple of faucets some test coins and when I'm looking into the block chain this is what I see:
The public address is "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge"
I've received 3 "payments" from 3 different faucets (all on the same block).
But at the same time all of them where spend and when to the same address as on the prevues testes, and all of this happened on the same "block"
and based on the timestamps at the same time.
How can this be possible?
On the bright side we can rule out "a compromised" Electrum (which by the way I did downloaded from the official site + verified the signature)
"Transaction": [
{
"TransactionId": "02e8df6726862abb55f509882b0c8e461847bb4f06c30aa3bc7728fddf7af7c3",
"n": 1,
"value": "0.02844292",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "066c68d50edebc57dbb35e4a16c45cdc740c83e920b6d05c22a382904839d075",
"UsedN": 1,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.02821192"
}
]
}
},
{
"TransactionId": "5598cb033f74571b7008548c0d2934ee5a1473d49b916cfacf432848aea8dfee",
"n": 1,
"value": "0.00066664",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "e46c907ae25eeed9cb73c3fa095c21c2e36fdb7d597d13e693f52435330fff66",
"UsedN": 1,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.00043564"
}
]
}
},
{
"TransactionId": "65ceb923844fd8761751ab8584f4170ee6760b250e2ad19dcd66f5d8a618ce8d",
"n": 0,
"value": "0.00010000",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "6efbcda30b63948fba9bcae84976dfad16769feb593275a9cc34eff035a64726",
"UsedN": 0,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.00009488"
}
]
}
}
]
}
I've created another public KEY, this time I didn't even look at the prive key.
i've created on the wallet that I'm developing using NBitcoin library.
I'm compiling everything from source code
Then I requested to a couple of faucets some test coins and when I'm looking into the block chain this is what I see:
The public address is "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge"
I've received 3 "payments" from 3 different faucets (all on the same block).
But at the same time all of them where spend and when to the same address as on the prevues testes, and all of this happened on the same "block"
and based on the timestamps at the same time.
How can this be possible?
On the bright side we can rule out "a compromised" Electrum (which by the way I did downloaded from the official site + verified the signature)
"Transaction": [
{
"TransactionId": "02e8df6726862abb55f509882b0c8e461847bb4f06c30aa3bc7728fddf7af7c3",
"n": 1,
"value": "0.02844292",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "066c68d50edebc57dbb35e4a16c45cdc740c83e920b6d05c22a382904839d075",
"UsedN": 1,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.02821192"
}
]
}
},
{
"TransactionId": "5598cb033f74571b7008548c0d2934ee5a1473d49b916cfacf432848aea8dfee",
"n": 1,
"value": "0.00066664",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "e46c907ae25eeed9cb73c3fa095c21c2e36fdb7d597d13e693f52435330fff66",
"UsedN": 1,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.00043564"
}
]
}
},
{
"TransactionId": "65ceb923844fd8761751ab8584f4170ee6760b250e2ad19dcd66f5d8a618ce8d",
"n": 0,
"value": "0.00010000",
"scriptPubKey_address": "mwT5PqSoLCeojDhghhBdXFCMMwGYxb34Ge",
"datetime": "2022-10-21T17:06:49",
"Used": {
"UsedId": "6efbcda30b63948fba9bcae84976dfad16769feb593275a9cc34eff035a64726",
"UsedN": 0,
"UsedDateTime": "2022-10-21T17:06:49",
"UsedTo": [
{
"scriptPubKey_address": "mjuKUaEPi2FXEtRNZRNUxdHAf7499npQ3j",
"n": 0,
"value": "0.00009488"
}
]
}
}
]
}
Re: funds immediately leaving electron wallet after receiving from TestNet faucet
This is the "about"
--------------------------
Version 4.2.2
Electrum's focus is speed, with low resource usage and simplifying Bitcoin. You do not need to perform regular backups, because your wallet can be recovered from a secret phrase that you can memorize or write on paper. Startup times are instant because it operates in conjunction with high-performance servers that handle the most complicated parts of the Bitcoin system.
Uses icons from the Icons8 icon pack (icons8.com).
--------------------------
--------------------------
Version 4.2.2
Electrum's focus is speed, with low resource usage and simplifying Bitcoin. You do not need to perform regular backups, because your wallet can be recovered from a secret phrase that you can memorize or write on paper. Startup times are instant because it operates in conjunction with high-performance servers that handle the most complicated parts of the Bitcoin system.
Uses icons from the Icons8 icon pack (icons8.com).
--------------------------