On 02/23/2015 09:53 PM, Andy Schroder wrote:
I was saying provide a public key via NFC (or a public key fingerprint
and then send the full public key over bluetooth). Instead of providing
a new public key on each tap, why can't the payee just stop accepting
connections from new parties on that
Does this not also require the BT publication of the script for a P2SH
address?
You mean if the URI you're serving is like this?
bitcoin:3aBcD?bt=
Yes it would. I guess then, the server would indicate both the script, and
the key within that script that it wanted to use. A
On 02/24/2015 11:49 AM, Andy Schroder wrote:
Hello,
I think were talking about a lot of the same things. There is one key
piece of information that I was not thinking about until you made it
clear. Why the payee needs to identify the payer. In my fuel pump
application, they really don't, so
Hi Mike,
Thanks for the feedback and letting me know that my earlier emails fell
victim to spam.
My scheme might be better because it would add further incentives for
running full nodes. A full node can be run on even a cheap laptop. In my
experience, once a person new to bitcoin accepts it as
Hello,
I think were talking about a lot of the same things. There is one key
piece of information that I was not thinking about until you made it
clear. Why the payee needs to identify the payer. In my fuel pump
application, they really don't, so I wasn't thinking closely about these
other
Andy Schroder
On 02/23/2015 10:09 AM, Jan Vornberger wrote:
Hey!
On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
It's maybe not a bad idea for the wallet to try all payment_url
mechanisms in parallel. Should we add this as a recommendation to
wallets in TBIP75?
It doesn't
This is an interesting idea from the standpoint of trying to incentivize
people to run nodes, though from a high level it seems to just be adding
complexity to the current process by which nodes 'endorse' blocks. When a
node receives and validates a block it then informs its peers of the new
On Tue, Feb 24, 2015 at 01:14:43AM -0500, Andy Schroder wrote:
I've had similar issues where the NFC device has to be disconnected
and reconnected. I've got lots of error checking in my code on the
NFC device, which helps, but still has problems sometimes. I've
found if I limit how quickly a
We can change resource to Session ID if you want.
I think the URL scheme should be:
bitcoin:[address]?r=bt:macs=PublicKey
But when connecting to the mac, the client indicates the SessionID in
the header, and as you say, SessionID is derived in some way from PublicKey.
This is a slightly
Thanks for the feedback and questions. Answers inline.
On Tue, Feb 24, 2015 at 9:54 AM, Jameson Lopp jameson.l...@gmail.com
wrote:
This is an interesting idea from the standpoint of trying to incentivize
people to run nodes, though from a high level it seems to just be adding
complexity to
The list appears dead, this is a test.
e
signature.asc
Description: OpenPGP digital signature
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with
It would appear that the Bitcoin Foundation has decided that their
next two seats would be decided by miners. (More information
available at:
https://bitcoinfoundation.org/forum/index.php?/topic/1255-blockchain-voting/#entry13453
)
Unfortunately, they seem to have not provided the software
Andreas' wallet supports this, but don't do it. Payment requests can get
larger in future even without signing. Exploding the capacity of a QR code
is very easy.
Instead, take a look at the Bluetooth/NFC discussion happening in a
different thread.
On Tue, Feb 24, 2015 at 4:58 PM, Oleg Andreev
On 02/24/2015 02:50 PM, Andy Schroder wrote:
We can change resource to Session ID if you want.
I think the URL scheme should be:
bitcoin:[address]?r=bt:macs=PublicKey
This is a question of proper URL semantics, as applied to the bt scheme.
From rfc3986 [Uniform Resource Identifier (URI):
Having stakeholders endorse blocks has, according to you, the benefits
of increasing the number of full nodes and making a 51% attack more
expensive. It seems to me it would have the opposite effects and other
negative side effects. Any stakeholder that has won could just be
running an SPV
I definitely need to have an deeper understanding of that paper before
proceeding. Thanks for the reference!
On Wed, Feb 25, 2015 at 4:58 PM, Andrew Lapp la...@purdue.edu wrote:
Having stakeholders endorse blocks has, according to you, the benefits
of increasing the number of full nodes and
16 matches
Mail list logo
