Bitcoin Dev

22 Apr 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 Apr 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 Apr 2025 22:08

hashcat has a mode for those

Bitcoin Dev

18 Apr 2025 00:07

it seems to be it's 546 for p2pkh/p2sh and 294 for segwit v0/v1

Bitcoin Dev

17 Apr 2025 23:53

Can anyone point me to a reference to check what is the dust limit in bitcoin core's default relay policy?
I found the GetDustThreshold method inside policy.cpp, but I don't know C++ and can't understand it.

I know it's 546 for P2PKH, but can't grasp for P2SH-P2WPKH, P2WPKH and P2TR.
Segwit admits lower values, like 300 sats.

This is the code:

    size_t nSize = GetSerializeSize(txout);
    int witnessversion = 0;
    std::vector<unsigned char> witnessprogram;

    // Note this computation is for spending a Segwit v0 P2WPKH output (a 33 bytes
    // public key + an ECDSA signature). For Segwit v1 Taproot outputs the minimum
    // satisfaction is lower (a single BIP340 signature) but this computation was
    // kept to not further reduce the dust level.
    // See discussion in https://github.com/bitcoin/bitcoin/pull/22779 for details.
    if (txout.scriptPubKey.IsWitnessProgram(witnessversion, witnessprogram)) {
        // sum the sizes of the parts of a transaction input
        // with 75% segwit discount applied to the script size.
        nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);
    } else {
        nSize += (32 + 4 + 1 + 107 + 4); // the 148 mentioned above
    }

    return dustRelayFeeIn.GetFee(nSize);

Bitcoin Dev

12 Apr 2025 18:03

what's the correct flag for setting btcd to use testnet4? i can see on the github repo it's been added and i'm running the latest version but i cannot work out how to enable it. trying to specify on the terminal and the config file doesn't work

Bitcoin Dev

12 Apr 2025 17:29

Bitcoin Core v28 or later

Bitcoin Dev

12 Apr 2025 17:25

i mean, will updating bitcoin core automatically move me to testnet4

Bitcoin Dev

12 Apr 2025 17:20

it's all mined, i wanted to try and mine some testnet coins

Bitcoin Dev

12 Apr 2025 17:18

Testnet4 launched last year 🫠

Bitcoin Dev

01 Mar 2025 13:37

Is there any Bitcoin nodes that are "Made in the USA"?

Bitcoin Dev

25 Feb 2025 09:20

"Setgenerate True 1"

I need it! And I'm interested in not generation all of my rewards/keys, just the keys that I sent Bitcoin too, and maybe one or two 'Select' Block Rewards. Which may require a panel to view 'DumpWallet' files in the Bitcoin system.

Is it possible to ask Bitcoin Devs to this, specifically for me, as many others seem uninterested in support the original Legacy Wallets and CPU Mining.


Thanks.

Bitcoin Dev

03 Feb 2025 22:18

Did they delete the BTC Lightning group or renamed it some how, i cant find it anymore ?

Bitcoin Dev

17 Jan 2025 14:15

I just said it was like a brc20 to dumb it down

Bitcoin Dev

17 Jan 2025 14:06

then it makes even less sense to use the BRC20 anti-pattern

Bitcoin Dev

22 Apr 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 Apr 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 Apr 2025 05:35

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

Bitcoin Dev

17 Apr 2025 23:55

well, this is the info I need:
size_t nSize = GetSerializeSize(txout);

Bitcoin Dev

12 Apr 2025 18:13

nvm, it's not been put into the latest release yet, cloning the github repo and building it works fine

Bitcoin Dev

12 Apr 2025 17:30

ok thanks, i'll check it out :)

Bitcoin Dev

12 Apr 2025 17:28

IIRC you can run it with the -testnet4 flag

Bitcoin Dev

12 Apr 2025 17:22

Yes that's testnet3. Check out https://testnet4.com/

Bitcoin Dev

12 Apr 2025 17:19

is this testnet3? tbtc . bitaps . com

Bitcoin Dev

12 Apr 2025 03:12

will the bitcoin testnet chain ever be reset?

Bitcoin Dev

26 Feb 2025 18:41

hey there, can I DM ?

Bitcoin Dev

07 Feb 2025 11:54

@lightningd

Bitcoin Dev

22 Jan 2025 21:18

refer to bitcoin forum or Ordicord discord server for ordinals or brc20 related discussion

Bitcoin Dev

17 Jan 2025 14:15

It was made before BRC20s too

Bitcoin Dev

17 Jan 2025 14:01

Try asking the bitcoin ceo