I agree, audio-based transference isn't really great for a podcast or radio
ad. It could be used to transmit payment details between phones that don't
have cameras, though. I think it would be better to define a standard for
transmitting information over audio, but not define what information is to
thats how i thought it worked originally, but im not well versed on that,
so i took his word for it
On Aug 10, 2016 12:38 PM, "Pieter Wuille via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
> wrote:
> > By sending a
On Wed, Aug 10, 2016 at 7:28 PM, Erik Aronesty via bitcoin-dev
wrote:
> By sending a public seed, there's no way for someone to use the transmitted
> address and trace the total amount of payments to it.
Worse. By revealing a public seed, anyone who has seen it (= anyone
who ever pays you throug
By sending a public seed, there's no way for someone to use the
transmitted address and trace the total amount of payments to it.
On Aug 10, 2016 12:02 PM, "Daniel Hoffman via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Erik
> What would be the advantages of transmitting a BIP
Erik
What would be the advantages of transmitting a BIP32 public seed, instead
of a plain address?
Theo
I didn't really think of that, but that's genius.
On Wed, Aug 10, 2016 at 6:49 AM, Theo Chino via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Another use for the audio would
Another use for the audio would be for watches that can listen but can't
use a camera (ie: Samsung S2), so sound would be great.
On Wed, Aug 10, 2016 at 7:42 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> NOTE:
>
> Addresses aren't really meant to be broadcast
> Signed by the key pair that was referenced in the output of the on-chain
> transaction?
Signed by the key pair referenced in the private output.
> (Bob in my example, actually)
I misread your example. If it was Bob, then the troll couldn't
generate the correct spend proof because he didn't s
This troll is harmless. A duplicate spend proof should also be signed
by the same user (Alice, in your example) to be considered a double
spend.
2016-08-09 3:18 GMT+03:00 James MacWhyte :
> One more thought about why verification by miners may be needed.
>
> Let's say Alice sends Bob a transactio
> That is a good point. As you said, it puts a lot more burden on the coin
> holders. One big downside would be data management. Instead of simply
> backing up a single HD private key, the user would have to back up entire
> histories of every output that has been sent to them if they want to secur
> Instead of a hash function you may use a keyed hash function (HMAC) where
> the key is just the random string. They key needs to be stored in the
> history of the coin to allow for verification.
This is nearly equivalent. The sole purpose of the blinding factor is
to increase the search space a
> The OP's proposal sounds quite similar to my earlier one along similar lines:
>
>https://petertodd.org/2016/closed-seal-sets-and-truth-lists-for-privacy
Similar indeed, thank you for the link.
2016-08-09 0:53 GMT+03:00 Peter Todd :
>
> On Mon, Aug 08, 2016 at 09:41:27PM +, James MacWhy
NOTE:
Addresses aren't really meant to be broadcast - you should probably be
encoding BIP32 public seeds, not addresses.
OR simply:
- Send btc to r...@q32.com
- TXT record _btc.rick.q32.com is queried (_..)
- DNS-SEC validation is *required*
- TXT record contains addr:[]
Then you can just say,
Have you considered CDMA? This has the nice property that it just sounds
like noise. The codes would take longer to send, but you could send
multiple bits at once and have the codes orthogonal.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundat
13 matches
Mail list logo
