|
561
|
Bitcoin / Bitcoin Discussion / Re: Is FullRBF allowing double spend?
|
on: September 04, 2023, 11:46:51 AM
|
Seems that the “Vending machine” that satoshi idealize not longer exists on mainnet So resuming - The instant Vending machine is possible only with lightning network, in mainnet it need to wait
- On mainnet those vending machines are not instant and need to wait up to 3 confirmations of the TX.
- Without confirmations all UXTOs can be double spending with FullRBF feature. (This is not enabled by default, but seems that is getting widely adopted)
Thank you all for your replies and thoughts
First of all, I'd kindly ask you to lower the height of your images as they take too much space.
Let me change it, I used to use imgur and always used lower size images, but sadly that hosting is not longer working on bitcointalk. |
|
|
|
|
562
|
Bitcoin / Bitcoin Discussion / Is FullRBF allowing double spend?
|
on: September 03, 2023, 08:46:00 PM
|
Based on my experience, yes. Here is the history, in my telegram group some users were talking about the RBF flag and how this allow you many things from bump the fee to increment the priority of your transaction, up to change the destination address and amounts, even return the balance minus fee to the source address or some other address under you control. That is some OK in the most of the cases, but some user reach me privately to show me that is not necessary to have the RFB flag enable in a TX to be replaced or modified, this is a FullRBF This user send me some dust amount to my address and some of his addresses. The original TX doesn’t have the RFB flag. After some days of the TX waiting in mempool, he do a FullRBF twice, first of it was changing the destination address to another address and 8 minutes later a second FullRBF changing the destination once again to my address. Images Original TX  First FullRFB  Second FullRFB  Final TXID: 942a454340c5115d769a16aad85b85a19875bb2f5e544de1b776570b76294f62If he hadn't performed that second FullRBF the dust amount would have ended in one of his addresses. This makes me think about the post of satoshi about the vending machine. What if a dishonest user sends a TX with low Fee (1 Sat/vB) to a vending machine, the machine releases the product, and after some time that user performs a FullRBF changing the destination address to one of his own addresses? I like the FullRBF feature to bump the fee. But i also see it as some kind of loophole for those some scenarios So the question about this is: what do you think about FullRBF, does it allow double spend or not? |
|
|
|
|
563
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: September 03, 2023, 11:15:41 AM
|
Is there a way to determine if a point on the curve is even or odd?
if i have a satoshi each time that i see that question... Sadly there is no way to determine if a point in the curve is odd or even, also there is no way to determine if bit in any position is 1 o 0 that would totally break ECDSAI already try a lot of things to try to anwser that question, but none of them works and actually i really give up that way, my recomendation is not lose time in that topic (Unless you are full cryptographer with wide knowledge in that field) Welcome to the club by the way. |
|
|
|
|
564
|
Local / Español (Spanish) / Re: Primer halving sin dinero gratis.
|
on: September 03, 2023, 03:36:43 AM
|
Personalmente creo que hace rato que la comunidad sobrestima los halvings. Yo creo que el futuro del mercado de BTC tiene más que ver con una mayor adopción que con una reducción de la "oferta monetaria" por parte de mineros. No digo que la oferta limitada no sea importante.
Yo tambien pienso que los halvings si estan un poco sobrevalorados si bien si son importantes, solo es un lado de la moneda esto es el lado de la oferta de bitcoin se reducira un poco, pero la demanda como mencionas tiene que ver mas con la adopción y la verdad nos estamos quedando muy atras. Pero los mineros hoy en día solo representan una fracción de 1-2% del volumen de trading de BTC de unos ~10-15 mil millones de dólares por día (y estamos hablando de semanas con muy poco volumen). Que esta en el próximo halving se reduzca a 0,5 a 1% no me parece muy significativo.
Tienes el Source de esta informacion? me gustaria leer mas al respecto. El tema de los Halving tiene que ver con que el costo real de produccion se podria incrementar. Citando a satoshi: The price of any commodity tends to gravitate toward the production cost. If the price is below cost, then production slows down. If the price is above cost, profit can be made by generating and selling more. At the same time, the increased production would increase the difficulty, pushing the cost of generating towards the price. Sin embargo creo que esto tarda algunos años en reflejarse |
|
|
|
|
565
|
Bitcoin / Project Development / Re: Keyhunt - development requests - bug reports
|
on: September 03, 2023, 02:18:44 AM
|
Just been watching the threads go by in random mode.
I notice that the first byte never seems to go below 0x7f. usually OxB -0xF range. is it just me? or perhaps the way the display is set.
Hi thank to point this, it is not exactly an issue, Keyhunt just needs a little guidance from you if you want to target a specific range. Let me explain how you can do this effectively. Keyhunt by default, it searches exclusively on bit 256, to avoid this limitation, you can specify the range you're interested in using the '-r' option. -r 1:fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 In the code above, '-r' allows you to set a range, and the numbers following it define the range. By specifying the range you want to target, you can make Keyhunt work exactly as you need it to. Just a personal question, what are you looking in the 256 bit range? Usually keyhunters only target the lastest avaiable puzzle in this case puzzle 130 with -b 130 you can specify the exact range of that puzzle. Publickey: 03633CBE3EC02B9401C5EFFA144C5B4D22F87940259634858FC7E59B1C09937852 ./keyhunt -m bsgs -f file.txt -R -k 128 -S -t 8 -M -b 130 If you have any more questions or need further clarification, feel free to ask. Happy hunting! |
|
|
|
|
566
|
Bitcoin / Bitcoin Discussion / Re: UTXOs Linking Percentage to an address
|
on: September 02, 2023, 06:05:49 PM
|
You care about privacy and try to merge UTXOs, is it something worth to consider for your privacy?
Let's say you coinjoin six outputs of 0.05 BTC, but then let each one get 5 free remixes before you stonewall them. That's significantly better and much harder to track. ..... Good luck to anyone trying to link those particular outputs together.  Do you see that i am getting mixed anwsers ? Well that debate will be endless. I am goint to add the percentage script to the uxtotrack tool just to see if it is useful or not. Regards! |
|
|
|
|
567
|
Bitcoin / Bitcoin Discussion / imagining what he will be like the last halving
|
on: September 02, 2023, 02:04:48 PM
|
|
Well most of us are waiting the next bitcoin halving and speculate about how it will affect the network, mining, fees, and prices
But I wonder how the bitcoin environment will be in years of the last halving. (I know i am not going to live to see that but in any case i want to dream a little with that).
So, picture this: It's near the year 2134 or 2138, and we've experienced the last-ever bitcoin halving. At this point, miners are going to get only 1 Satoshi per mined block, plus transaction fees. It's a far cry from the current scenario and for the next period of 4 years only 210000 new satoshis will be created. That made me think that we need to start trying to save every satoshi available.
For miners, it's safe to assume that transaction fees will go through the roof. As the mining reward shrinks, miners will need to get creative to keep their operations profitable. They might start looking into greener, more sustainable energy sources to cut costs and invest in better mining hardware to maximize their returns.
On the other hand, for folks like us, the incentive to spend our bitcoins may decrease. With rewards diminishing and fees on the rise, there's a stronger argument for holding onto our digital treasure unless it's absolutely necessary. Think of it as a futuristic savings account where every satoshi saved feels like a victory.
In the end, none of us may live to see the year 2138, but it's exciting to imagine how the world of bitcoin will evolve after the last halving. The balance between mining rewards and fees, along with the motivations of miners and users, will surely transform. Who knows what kind of innovative solutions and changes are in store? Until then, let's keep dreaming and HODLing those precious satoshis!
What are your thoughts about the future of bitcoin in times of the last halving ?
|
|
|
|
|
568
|
Bitcoin / Bitcoin Discussion / Re: UTXOs Linking Percentage to an address
|
on: September 02, 2023, 01:08:46 PM
|
Thank you for your reply Nice Whirlpool I think the first question is "What are you trying to achieve?"
what i want to achieve is having a way select the ideal uxtos in some Stonewall TXFor example if i select 4 UXTOs of different address, but two of them (A and B) have the relationship that i mentioned in the OP, It may means nothing but there may be also other factors (Time of that common Address do that transaction, block height, amounts like you mention, and maybe others) But if the fourth selected UXTOs all have some Address in common the things may change. What i want to determine is until what point of it is OK merge those UXTOs in a TX |
|
|
|
|
569
|
Bitcoin / Bitcoin Discussion / UTXOs Linking Percentage to an address
|
on: September 02, 2023, 02:36:06 AM
|
Hello Have you ever wondered about the fascinating connections between inputs and outputs in a bitcoin Transaction? I experimented with the Boltzmann tool, which proved to be quite effective when analyzing a single transaction. However, my curiosity led me to develop a python tool ( uxtotrack) to examine whether UTXOs share common addresses or TXIDs deep within their ancestry lines. The question that brought me my interest here is: How closely related can supposedly two "independent" UTXOs be if they share a common link buried deep within their ancestry? Example: UXTO A and B have some common address in its ancestry line of transactions but in different levels just to put some tags and numbers, Address X is common in UXTO A ancestry Level 7 and Address X is common in UXTO B ancestry Level 10. Is there some formula/equationor work already written on that? In this example we can imagine that some public exchange send balance to those addresses, or any other similar event, like those two address were paid by the same person or entity. I already did some test with percentages backwards in some UXTO and most of them reach less than 0.01% percent of linkability after 6 or 7 levels of ancestry So, what does this mean for the linkability of those address? Essentially, when we see less than 0.01% linkability after several levels of ancestry, it indicates that a specific address (in this case, Address X) contributed only a negligible fraction of the total balance in the UTXO we're examining. I don’t know if this is a correct approach but I can't think of another way. Now, the question arises: When does an ancestor become insignificant or unrelated to a specific UTXO? I propose two options for consideration: - When it contributes less than a Satoshi of the Balance of the UXTO
- When it contributes less than 547 Satoshis of the balance of the UXTO
What are your thoughts about this topic? |
|
|
|
|
570
|
Bitcoin / Project Development / utxotrack
|
on: September 02, 2023, 12:51:38 AM
|
Hey everyone. Lately I get some interest about Bitcoin transaction privacy. I've been testing various scenarios on the testnet, and I've come to realize that it can be quite challenging to determine if your UTXOs share previous TXIDs or addresses in common. Manual tracking can be especially tricky. Here are a couple of resources I found that might be helpful: Know Your Coin Privacy (KYCP): https://kycp.org/https://oxt.me/However, please note that these resources still require some manual searching, and the results may not always be conclusive at first sight To address this challenge and assist me in selecting the right UTXOs for certain transactions having considering the privacy and other factors, I develop a small and not complex script in python Utxotrack available on github This script works seamlessly on both the Bitcoin mainnet and testnet. Currently, it's a standalone script, but I plan to expand its functionality in the future if you like it. The main idea is to identify any instances where transactions share reused addresses or TXIDs across different levels of their ancestry. It's a step toward enhancing privacy in Bitcoin transactions. Just to clarify, I didn't really check if there are other scripts for this. I'm just into coding, and this task seemed like a relatively simple one to work on. I open this topic to get feedback about the script and get some interesting ideas that could be helpful to this community. If you want to talk about UTXOs privacy or some other topic I suggest open a new topic for it. Executing the script. Missing arguments expected:
python3 utxotrack.py <network> <txid> <level> Let’s to said that you have an utxo in some TXID python3 utxotrack.py bitcoin a95e587f7ed6813b567c291f91db80785c5e5a3d73f97222f0d3dfcf04e988f3 1 Level 0 TX a95e587f7ed6813b567c291f91db80785c5e5a3d73f97222f0d3dfcf04e988f3 have 1 inputs and 1 outputs.
inputs:
adbed3a8ea57bb321ed93a39b5a7ef4424de876a7c2ebb254c82517d6555697e 1875 from bc1qyp8nuqvwfydg9svlm9cgyz3h4krfcrglue786g
Total involved addresses: 1
bc1qyp8nuqvwfydg9svlm9cgyz3h4krfcrglue786g : 1
Total involved txids: 1
adbed3a8ea57bb321ed93a39b5a7ef4424de876a7c2ebb254c82517d6555697e : 1 But if we increment the level to 3 or 4 the things become more interesting, the program mark with a different color those TX and address that appear more than one time python3 utxotrack.py bitcoin a95e587f7ed6813b567c291f91db80785c5e5a3d73f97222f0d3dfcf04e988f3 4 Level 0 TX a95e587f7ed6813b567c291f91db80785c5e5a3d73f97222f0d3dfcf04e988f3 have 1 inputs and 1 outputs.
inputs:
adbed3a8ea57bb321ed93a39b5a7ef4424de876a7c2ebb254c82517d6555697e 1875 from bc1qyp8nuqvwfydg9svlm9cgyz3h4krfcrglue786g
Level 1 TX adbed3a8ea57bb321ed93a39b5a7ef4424de876a7c2ebb254c82517d6555697e have 2 inputs and 2 outputs.
inputs:
Detected repeated TX id: 5c6dded31f8db448690e7eeb57eb340029335b84f2d5c9bb0475527a1f505f24
Detected repeated address: bc1qzc6rjlyrqt6vfp5hjlhwx6nqeahyt4tqe6lcnr
5c6dded31f8db448690e7eeb57eb340029335b84f2d5c9bb0475527a1f505f24 3651 from bc1qzc6rjlyrqt6vfp5hjlhwx6nqeahyt4tqe6lcnr
5c6dded31f8db448690e7eeb57eb340029335b84f2d5c9bb0475527a1f505f24 3685 from bc1qzc6rjlyrqt6vfp5hjlhwx6nqeahyt4tqe6lcnr
Level 2 TX 5c6dded31f8db448690e7eeb57eb340029335b84f2d5c9bb0475527a1f505f24 have 2 inputs and 10 outputs.
inputs:
Detected repeated address: 3P8KDNJD19M2pZVkozVKdxqxPh5VhyXod5
bc918ad6752795087494f07b3f8d69bc1e2d0a49865e01606e54d1afe2e5a619 1073 from 3P8KDNJD19M2pZVkozVKdxqxPh5VhyXod5
e57f2edf96c3a1aaa2032c87d9a6f6df9a2709107cbf0d3379067e428d9f7afc 38773 from 3P8KDNJD19M2pZVkozVKdxqxPh5VhyXod5
Level 3 TX bc918ad6752795087494f07b3f8d69bc1e2d0a49865e01606e54d1afe2e5a619 have 1 inputs and 2908 outputs.
inputs:
598de09d64c8a1e565524650b2127c8a31b66576b509cb49d86097a7449572ee 454147444 from bc1qkqa93cvc7mcy5jjw52dujfkm2mz96cfyjvwarn
Level 3 TX e57f2edf96c3a1aaa2032c87d9a6f6df9a2709107cbf0d3379067e428d9f7afc have 1 inputs and 2908 outputs.
inputs:
159345d616aafeb9de437afe9f13aa68ecc678550b42e5005011c5f315f2b6e3 640000000 from bc1q54rqt77uh77ftgf5hahf2zf2sasyrwwxxgmkam
Total involved addresses: 5
bc1qyp8nuqvwfydg9svlm9cgyz3h4krfcrglue786g : 1
bc1qzc6rjlyrqt6vfp5hjlhwx6nqeahyt4tqe6lcnr : 2
3P8KDNJD19M2pZVkozVKdxqxPh5VhyXod5 : 2
bc1qkqa93cvc7mcy5jjw52dujfkm2mz96cfyjvwarn : 1
bc1q54rqt77uh77ftgf5hahf2zf2sasyrwwxxgmkam : 1
Total involved txids: 6
adbed3a8ea57bb321ed93a39b5a7ef4424de876a7c2ebb254c82517d6555697e : 1
5c6dded31f8db448690e7eeb57eb340029335b84f2d5c9bb0475527a1f505f24 : 2
bc918ad6752795087494f07b3f8d69bc1e2d0a49865e01606e54d1afe2e5a619 : 1
e57f2edf96c3a1aaa2032c87d9a6f6df9a2709107cbf0d3379067e428d9f7afc : 1
598de09d64c8a1e565524650b2127c8a31b66576b509cb49d86097a7449572ee : 1
159345d616aafeb9de437afe9f13aa68ecc678550b42e5005011c5f315f2b6e3 : 1 It is normal that a single utxo have some repeated address or TXID in its ancestors a lot of explanations can fit here (Consolidations in the same address, Change address equal to the source address, mixers, etc…) But the idea is to check different utxos and check if they share something in common up to 5 levels of ancestors (I said 5 here because more than it can be very messy some times, i am going to open a topic asking for that ) Feel free to check out the script and share your thoughts. I'm also open to suggestions and improvements, so please let me know if you have any ideas to make it even more effective. |
|
|
|
|
571
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: September 01, 2023, 07:38:48 PM
|
its not blind searching
No its not blind search it actually a dummy search @kalos15btc There is no relationship if two publickey keys share a partial RMD hash even if you found an address with 159 bits exactly equals to another address, there is not going to be a relationshipt between the publickeys I have this rmd160 as my address
000000009f012a539f3df386f0bddbb874af55ec
I should get to work and find this address 1111111111111111111114oLvT2
With rmd160 of
0000000000000000000000000000000000000000 ? Lol I'm done.
This time I agree with you @digaran |
|
|
|
|
572
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: August 31, 2023, 09:31:49 PM
|
Maybe I know too little information about it. I think I have some idea now, not sure if I am correct about it. By subtracting known 130 public key to lower bits to find the lower bits private key, once gotten that private key you do an inverse of lower bit private key back to 130 bits. Am I right?
Yes that is correct if you have some case like this: P130 - PA = X
P130 - PB = Y
P130 - PC = Z
...
P130 - PM = N if you found the privatekey of any X, Y, Z or N you only need to apply the inverse process to get the Private key of P130, you only need to be aware of what are the values of PA,PB PC and PM the same appy for other operations like addition, multiplication and division Regards! |
|
|
|
|
573
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it
|
on: August 29, 2023, 03:44:50 PM
|
I am not coder, so don't know how to build.
Could you please build this for non-coders?
Also how fast is this using CPU?
Thanks
Hi you don't need to be a coder to use the program just follow the instrucctios to compile it under any WSL enviroment. For CPU my program is one of the fastest available today, Address/rmd160 mode can reach some Millions keys per second on a laptop, up to 100 Millions keys per second on a High end CPU. For Mode BSGS that use RAM to store precalcualted data you can reach some Petakeys/s scanning for a single publickey. Regards! |
|
|
|
|
577
|
Bitcoin / Project Development / Re: Javascript Taproot Address Generator for Browser
|
on: August 25, 2023, 06:04:11 PM
|
I know, but testnet for itself dont teach us how to generate Taproot addresses with our own code.
I don't buy it, the main difference between mainnet and testnet is that Testnet addresses have different byte prefix. So if you manage to do a code to generate a taproot address in testnet you only need to change the prefix to generate it on mainnet. Testnet can indeed be a valuable tool for learning how to generate Taproot addresses with your own code. Testnet is valuable for us as developers to experiment and test our code without using real funds. Please don't burn satoshis on mainnet. By the way I support you to learn to do it by yourself, that kind as self learning is good. Regards. |
|
|
|
|
580
|
Bitcoin / Bitcoin Technical Support / Re: TX Broadcast timestamp
|
on: August 24, 2023, 03:40:27 PM
|
Try Blockcypher's API.
Their blockexplorer has a simple "x hours/days/months ago" message but the API call for "txs" has 'received' timestamp which is when they've received the transaction into their mempool.
Thank you so much Exactly what i am looking for Any reason you need to know the exact time a transaction was broadcasted? Because I personally don't see any use case  I agree with you, usually that information is worthless, but i get some curious about some transactions the other day and i am doing some research, if you are interesting i can let you know when i publish it. Regards! |
|
|
|
|
Show Posts
