Bitcoin Dev

18 May 2025 23:50

geyser.fund might help

Bitcoin Dev

18 May 2025 10:26

Would love to get feedback from fellow BitcoinDevs / BitcoinMaxis how you would approach a Bitcoin native funding process with all logic of collecting VC but just decentralised and no shit coins involved. We basically want to accelerate Bitcoin adoption as much as humanly and technologically possible.

Bitcoin Dev

18 May 2025 10:20

Hi, is anyone familiar with
• Lightning-native authentication or access models (e.g. LNURL-pay / LNURL-auth)
• Snapshot-based BTC distribution (e.g. via address map or PSBT system)
• Taproot-based commitment schemes
• Liquid-issued assets (less preferred due to trade-offs)
• Possibly even Nostr-based participation tracking
?

Bitcoin Dev

04 May 2025 21:35

not sure, you can reach out and ask them

Bitcoin Dev

04 May 2025 20:12

https://www.lopp.net/bitcoin-information/recommended-wallets.html#recoveryservices

Bitcoin Dev

04 May 2025 19:04

imo that's not solid security; you won't always achieve adequate entropy; subject to brute dictionary attack; plausibly llm's could even be used in exploit if part of your recovery phrase was known. stick with BIP39 standard when choosing seeds and choose 15+ randomly from the 2048 listed

Bitcoin Dev

04 May 2025 02:11

its a futile fight, take the win by collecting their full fees and not poluting the chain less with less unspent utxos to increase security of everyone

Bitcoin Dev

03 May 2025 22:35

expiration, pruning, size*time fees, and shared mining rewards... then we have hard coded abuse prevention feedback mechanisms instead of a free for all

Bitcoin Dev

03 May 2025 22:31

can we split the fees generated by OP_RETURN data over the next n blocks where n is tied to the size of the OP_RETURN?

Bitcoin Dev

03 May 2025 13:17

I have coded some stuff and shit projects on ordinals and runes etc.
Now I found them like... they are adding rubbish inside bitcoin full nodes imo...

Bitcoin Dev

01 May 2025 19:34

https://antoinep.com/posts/relay_policy_drama/

Bitcoin Dev

01 May 2025 00:14

Yeah it removes links and @'s. Fixed it for you

Bitcoin Dev

22 April 2025 18:17

Improved Customer Experience: The feedback mechanism helps exchanges or services optimize their platforms based on real user feedback, ensuring that users feel heard and rewarded for their loyalty.




---

3. Payment Processor Feedback Optimization

Use Case Description: Payment processors or third-party services (e.g., Bitcoin payment gateways) can use the feedback address system to optimize services and improve user experience without being involved in the transactions themselves.

Scenario:
A Bitcoin payment processor, Processor X, provides users with an easy way to pay vendors using Bitcoin. While the processor facilitates payments, it wants to gather feedback about the user experience to enhance the service.

Feedback Address Usage:
The payment processor generates a unique feedback address, 1bc1feedbackprocessorX..., to collect user feedback independently of the transactions.

How It Works:

1. Customer E uses Processor X to make a payment to Vendor F.


2. After the transaction, Customer E is encouraged to submit feedback about their experience using Processor X to 1bc1feedbackprocessorX....


3. This feedback is cryptographically signed, ensuring its authenticity without revealing any transaction details.


4. Processor X uses the collected feedback to adjust its services, potentially offering improvements such as better UI/UX design or faster transaction processing, all while ensuring that Customer E’s financial privacy is preserved.



Benefits:

Independent Feedback Collection: Feedback is separated from the transaction, so the processor can gather valuable insights without compromising user privacy or interfering with the payment process.

Improved Services: By collecting feedback in this manner, the payment processor can improve its services without needing to know the details of the payments being made.

Privacy Preserved: The feedback mechanism does not interfere with the payment process or expose sensitive financial information.




---

Conclusion:

These use cases demonstrate how feedback addresses can be leveraged by brands, exchanges, payment processors, and other intermediaries to optimize services, gather feedback, and offer incentives without interfering with the core financial transaction. This creates a trust-based system where privacy is respected, and businesses can engage with users on a decentralized and transparent basis.

This system helps businesses improve their operations while ensuring that the financial transaction itself remains private and autonomous, with no direct connection to the feedback system. This can potentially revolutionize how brands, exchanges, and service providers collect user input and optimize their platforms, while maintaining the privacy and control of users over their financial interactions.

Bitcoin Dev

22 April 2025 18:16

This protocol does not require changes to the Bitcoin protocol but leverages existing cryptographic mechanisms (e.g., zkSNARKs, digital signatures) to implement the feedback address system.

Implementation:

1. Feedback Address Format:

Feedback addresses are defined as special Bitcoin addresses that start with a specific prefix (e.g., 1bc1feedback...).

These addresses are used only for the purpose of proving ownership and are not intended for receiving regular payments.



2. Proof Generation:

zkSNARKs or other similar zero-knowledge proofs can be used to generate proofs of ownership.

These proofs are verifiable on the blockchain but do not reveal any private keys.



3. Address Derivation:

Payment addresses are derived from the feedback addresses using a cryptographic formula (e.g., hashing both addresses together) that ensures the address is unique to the pair of parties.





---

Conclusion:

The feedback address protocol provides a simple, trust-based method for verifying ownership of Bitcoin addresses without revealing private keys. By using cryptographic proofs, it enables secure, private, and decentralized verification, ensuring that both parties can trust each other before engaging in a financial exchange.

Bitcoin Dev

21 April 2025 22:08

hashcat has a mode for those

Bitcoin Dev

18 May 2025 12:32

Sounds like you're looking for a crowdfunding solution like https://hub.angor.io/

Bitcoin Dev

18 May 2025 10:21

We are a team of 4 Engineers&Bitcoin Maxis who seek VC but decentralised and are exploring Bitcoin-native solutions

Bitcoin Dev

05 May 2025 01:36

to analyze the drive check

https://sleuthkit.org/autopsy/docs/user-docs/4.22.0/

to generate a list of potential keys for your recovery phrase try:

https://pastebin.com/VTvgRun3

Bitcoin Dev

04 May 2025 21:15

Which is the one to go to with a broken hard disc? Got a friend with some in mycelium wallet and broken Samsung Galaxy notepad. Needs serious lab work probably. Couldn't get to it with home equipment.

Bitcoin Dev

04 May 2025 19:53

I lost access to my wallet. I need this particular application. To repeat the key generation. I guarantee a reward.

Bitcoin Dev

04 May 2025 18:53

Good time of day. Tell me, I can't remember what kind of Bitcoin wallet it was. The master key/private key was generated from text using the brain wallet type. It was possible to choose the number of words for the initial phrase. As an example for a brain wallet, a text about sakura and cherry blossoms in the wind during rain was given.

Bitcoin Dev

04 May 2025 02:10

whenever you do any of this, people will just stop using OP_RETURN and use other more "destructive" methods to encode data

Bitcoin Dev

03 May 2025 22:32

If we can implement expiration can we charge fees of size*duration?

Bitcoin Dev

03 May 2025 22:23

can we implement expiration and scheduled pruning on OP_RETURN data?

Bitcoin Dev

01 May 2025 23:34

Bitcoin is incentive incompatible in a strict sense (e g., IBD is a public good, yet purely rational nodes should all prune). However, to make Bitcoin more robust for the future we should be making it as close to incentive compatibility as possible.

This means accepting inscriptions and other forms of spam to the extent that they pay the required fee rate. Similar to the case with RBF, it isn't stable to rely on altruistic behavior. Anyway, it can't get worse than 4M WU per block (which, for opteturns concretely, it's below average block size).

That PR is 100% consistent with the refusal to "fix the filters". If we aren't fixing it it's preferable to remove the functionality, because OP_RETURN is the least polluting way to put data.

Bitcoin Dev

01 May 2025 17:15

What's this new talk of removing OP_RETURN restrictions?

https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ

https://github.com/bitcoin/bitcoin/pull/32359

Because client side hackers find exploits to stuff tidbits of data on chain - albeit it some of it useful - now we're going to roll out the red carpet to this activity for porn kings to graffiti the chain with externalities that nodes will have to store forever?

I find the notion of 32359 (and the decade long conversation) akin to saying we're going to get rid of pimpslapper and hal9000 in telegram chats because sometimes hackers find ways to send spam to the groups anyway.

@satoshi why did you switch sides on this ? we have a whole ecosystem of shitcoins to store data on. Why does bitcoin need this feature? how does this increase adoption as a global currency?

I don't think the price of hardware will scale as fast as chain bloat without limits on OP_RETURN. Shoot from the hip.. lets say we have 500GB chain now... we keep OP_RETURN 83bytes as is we're going to have 2TB chain in 20 years and hobby Bitcoin nodes are still a thing. We make OP_RETURN unlimited (4MB) and maybe we have 200-500TB chain and only big business can run a node.

is Bitcoin still Bitcoin if "running a node" has a $10k-50k SSD requirement?

And for what? To carry illicit graffiti? To be another EVM? A permanent pornhub for 4MB videos?

Is bitcoin a replacement for fiat currency or a do everything machine? Is a do everything machine ever as good as do one thing well machine?

Are we willing to risk forking the community? Which will be the "real bitocin" the one that adopts unlimited OP_RETURN or the original?

Are developers spending time focusing on privacy features and scaling fees down by introducing unlimited OP_RETURN? How does that fit why cypherpunk core values?

What happens when there is illicit data not broken in chunks but just there and raw on every node and fedgov gets involved? Its poking the sleeping tiger. The essence is supposed to be to use technology to make ourselves ungovernable not to use tech to taunt governance and call out their wrath.

What happens when someone figures out how to embed KYC into OP_RETURN and suddenly all the coins are traceable through every individual they touch?

Is it an enclusive financial ecosystem for all if small actors are priced out in fee terms by large actors hogging whole blocks?

What happens if this sudden change causes DoS attacks or network partitions?

What happens when fees are low during crypto winter and the graffiti gets thick? Come summer we all have new spam bloat to handle - forever? Now I want to send my coin to exchange on sell day and fees are $500 at the peak?

Are we sure that 4MB scripts embedded in OP_RETURN won't have security implications for everyone?

Is this or is this not a disruptive change that harm community cohesion?

Does anyone even remember the cyphernomicon? Please reread section 2.3

"totally anonymous, unlinkable"

unlimited OP_RETURN turns Bitcoin into a state business and a state surveillance machine

If KYC’d OP_RETURN data taints UTXOs, even privacy-conscious users could be exposed, contradicting voluntary, private transactions (Cyphernomicon 2.3.3).

I'd like to also toss an echo of the past into this OP_RETURN discussion... do you remember bitDNS?

https://satoshi.nakamotoinstitute.org/posts/bitcointalk/535/

"separate fates"

Bitcoin Dev

30 April 2025 20:49

admin wtf your bot deletes everything I post

Bitcoin Dev

22 April 2025 18:17

Additional Use Cases:

1. Brand Feedback Mechanism

Use Case Description: A brand or service provider (e.g., a cryptocurrency exchange or online store) can use the feedback address system to receive feedback from customers without directly interacting with the payment itself. This allows the brand to collect valuable feedback while maintaining the privacy of the parties involved in the transaction.

Scenario:
A cryptocurrency exchange, Exchange A, wants to receive feedback from its users about the transaction experience. While customers are transacting with each other (say, a customer purchasing a product with Bitcoin), the exchange still wants to be notified about the experience in the form of feedback.

Feedback Address Usage:
The exchange generates a special feedback address, 1bc1feedbackexchangeA..., which acts as a gateway for feedback. Users don’t send money to this address, but they instead send their feedback about the transaction or the service to this address, using cryptographic proofs to validate the feedback submission.

How It Works:

1. Customer A transacts with Customer B, but they are instructed to send feedback to 1bc1feedbackexchangeA... to share their experience with the exchange.


2. The exchange uses the feedback address to receive cryptographic proof of feedback submissions from customers.


3. The feedback does not affect the payment between the customers, which remains independent and private.


4. The exchange can then use the collected feedback to improve services or offer rewards for positive feedback, all while maintaining user privacy and ensuring that the payment remains between the two customers.



Benefits:

Decentralized Feedback: The feedback address remains separate from the actual financial transaction, ensuring customers’ private financial data is not exposed.

No Impact on Payments: The exchange or brand is not involved in the transaction, and customers are not forced to disclose any personal or financial details to the brand.

Optimized Services: Brands can gather insights and feedback without needing to involve themselves in the financial transaction, allowing them to optimize services based on real customer experience.




---

2. Cryptocurrency Exchange Fee Optimization

Use Case Description: A cryptocurrency exchange or service provider can use the feedback address system to optimize fees or rebates for users based on the feedback they receive, even though the users are paying each other directly.

Scenario:
An exchange, Exchange B, offers customers a reward or fee discount if they provide positive feedback about their transaction experience. This feedback is not directly linked to the actual payment being made between the users but is an additional layer to improve customer loyalty and experience.

Feedback Address Usage:
Customers are encouraged to send feedback about the exchange experience to a feedback address provided by the exchange. This address, 1bc1feedbackexchangeB..., is not involved in the financial transactions between customers but serves to gather insights.

How It Works:

1. Customer C sends Bitcoin to Customer D as part of a trade or purchase, and both customers complete the transaction.


2. Customer C and D, as part of their agreement with Exchange B, send feedback to the feedback address 1bc1feedbackexchangeB... after the transaction is completed.


3. The feedback is submitted with a cryptographic proof that the sender is part of the transaction and that they are providing legitimate feedback.


4. Based on the feedback collected, Exchange B can apply a discount to the fees of future transactions for the customer who left positive feedback, improving customer satisfaction without intervening in the original transaction.



Benefits:

User Incentives: By rewarding users for positive feedback, exchanges can improve customer retention and engagement.

No Impact on the Transaction: Customers still pay each other directly, and the payment remains private and autonomous.

Bitcoin Dev

22 April 2025 18:15

BIP: Feedback Address Protocol for Trust-Based Transactions

Abstract:

This BIP defines a method for generating and verifying a feedback address that allows two parties to create a trust-based payment address. The feedback address acts as a proof of ownership, and once both parties exchange and verify their feedback addresses through cryptographic proofs, they can generate a secure payment address for further transactions. This system is designed to prevent fraud and ensure that transactions are conducted between verified parties.

Motivation:

The need for this protocol arises from the desire to establish trust between two parties who are transacting. In many cases, it is crucial to confirm the legitimacy of the other party before engaging in any financial exchanges. By using feedback addresses, the protocol allows parties to prove ownership and ensure that the address belongs to them, while protecting their privacy with cryptographic proof (e.g., zkSNARKs).

Specification:

1. Feedback Address Generation:

Each party must generate a feedback address, which is a special address that signifies they are the rightful owner of a specific set of addresses.

This address will be based on a cryptographic structure that ensures only the owner can prove the ownership of the address. This can be done using zkSNARKs or similar proof mechanisms.



2. Proof of Ownership:

When Party A provides their feedback address to Party B, they must also provide a cryptographic proof showing that they control the feedback address.

Party B must similarly provide a proof of ownership for their own feedback address.

The proof can be a signed message or a zkSNARK-based proof that can be verified without revealing the private key.



3. Verification of Proof:

Each party verifies the other's proof using the public key associated with the feedback address.

If the proof is valid, both parties can confidently move forward with the next steps. If the proof is invalid, the transaction should not proceed.



4. Generating the Payment Address:

After both parties verify each other's feedback address and proof of ownership, they can generate a payment address.

This can be done by combining the two verified feedback addresses using a predefined formula or cryptographic tweak, ensuring the resulting address is unique to this specific interaction.

The address generation method must ensure that the transaction is private, and only the two parties involved can derive the payment address from the verified feedback addresses.



5. Blacklist and Restrictions:

If either party's feedback address is blacklisted or invalid, they cannot generate a valid payment address, and the transaction is prohibited.

The feedback address system also ensures that once a feedback address is used, it cannot be fraudulently reused or tampered with, ensuring ongoing trustworthiness.




Security Considerations:

Cryptographic Proof: The zkSNARKs or other zero-knowledge proofs ensure that the transaction can proceed without revealing private keys, preserving both parties' privacy.

Blacklist Management: The system can integrate with an optional blacklist mechanism, preventing malicious actors from engaging in the transaction.


Examples:

1. Party A and Party B:

Party A generates a feedback address: 1bc1feedbackdrggftthufrt.

Party B generates their own feedback address: 1bc1feedbackxyz....

Party A provides cryptographic proof of ownership for their feedback address.

Party B verifies Party A’s proof.

Party B provides cryptographic proof of ownership for their feedback address.

Party A verifies Party B’s proof.

Both parties generate a unique payment address for the transaction.




Rationale:

This approach ensures that both parties can trust each other without revealing private information. By leveraging feedback addresses and cryptographic proofs, we eliminate the need for centralized authority or external validation, thus empowering individuals with a decentralized mechanism for trust in peer-to-peer transactions.

Backwards Compatibility:

Bitcoin Dev

20 April 2025 05:35

hi everyone! has anyone found the password for wallet dat file?