On Tue, Jun 24, 2014 at 6:40 PM, Jorge Timón wrote:
>
> I think he means that the wallet shouldn't be running as much as it is
> currently doing.
> But yes, I think you're right about wallets and GUIs not necessarily
> mapping 1:1.
I haven't been talking about the GUI at all in this entire
conver
> On Jun 24, 2014, at 16:12, Gavin Andresen wrote:
>
> It would be silly to add a "generic stuff" field inside a container format
> that ALREADY has all the mechanisms necessary for forwards and backwards
> extensibility.
I agree. It would be even sillier to start specifying container formats
On Tue, Jun 24, 2014 at 3:00 PM, Gmail wrote:
> Ok, wanting structured data is a decent argument, but why this random
> arbitrary case in particular? There are hundreds of fields like this that
> people might want to use.
>
Protocol buffers are designed to be extensible, and there are hundreds o
Here's an idea for a BIP 70 extension to let wallets be scanned by merchant
bar code readers to start off a payment request flow instead of the other
way around (wallet scanning the merchant QR). Useful for brick and mortar
merchants and mobile wallet apps.
Motivation:
A mechanism is needed for m
I somewhat agree with Will (but also with Mike, Jeff, and Charlie.) I
think the idea of letting consumers know advanced details about the
transaction is good and defining these with strong types is also good.
Maybe an arbitrary set of accounting line items would be more
palatable. You could have a
On Tue, Jun 24, 2014 at 10:21:46AM -0400, Jeff Garzik wrote:
> On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn wrote:
> > Wallets would then be able to persist this data to disk and compete on cool
> > visualisations for how much money you saved over time.
>
> heh, this is a cool idea.
>
> It also
Ok, wanting structured data is a decent argument, but why this random arbitrary
case in particular? There are hundreds of fields like this that people might
want to use.
If we're going to support one random cosmetic field, we might as well support
them all with a generic structured data format
Seems like a nice idea.
On 24 June 2014 14:27, Mike Hearn wrote:
> Coinbase have started allowing merchants to set discounts for purchasing
> with Bitcoin. Seeing an individual discount is not very motivating as they
> tend to be small. Seeing them stack up over time can be more motivating
> be
On 6/24/14, Justus Ranvier wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 06/24/2014 09:07 AM, Wladimir wrote:
>> My main argument for the split is that full nodes and wallets have
>> completely different usage scenarios:
>>
>> - A wallet should be online as little as possible, id
>
> I think it should be made more clear what's the reference price for the
> discount.
>
That might be useful for merchants that already provide a series of
price-differentiated payment methods, yes. Will think about it.
> Also, currently PR are created by the payment processors afaik. How can
I think there is nothing wrong with having a numeric memo field, which
is effectively what this is. Structured rather than unstructured
data.
On Tue, Jun 24, 2014 at 11:15 AM, Gmail wrote:
>
>
>> On Jun 24, 2014, at 10:32, slush wrote:
>>
>> Sounds like marketing bullshit to me. It does not hav
I think it should be made more clear what's the reference price for the
discount. In Germany, we generally don't use credit cards but rather
"EC-Cards", which is already much cheaper. Or maybe for some merchants
the only alternative is cash, and they would still offer a Bitcoin discount.
Also, cur
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/24/2014 09:07 AM, Wladimir wrote:
> My main argument for the split is that full nodes and wallets have
> completely different usage scenarios:
>
> - A wallet should be online as little as possible, ideally only
> when you do transactions or wan
> On Jun 24, 2014, at 10:32, slush wrote:
>
> Sounds like marketing bullshit to me. It does not have even statistical
> meaning; well, you can "save" a lot of satoshis, but nobody tell you that the
> merchant cut you on BTC/USD exchange rate in tens of %.
People would also abuse this feature
>
> Sounds like marketing bullshit to me. It does not have even statistical
> meaning; well, you can "save" a lot of satoshis, but nobody tell you that
> the merchant cut you on BTC/USD exchange rate in tens of %.
>
Your own wallet can look up the exchange rate and compare it to what you're
gettin
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can "save" a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.
Payment protocol should not contain these fictional data, which has no real
meaning for the
>
> It also seems like it would be subject to instant inflation, as it's
> unprovable
The user knows the price that is on the website or menu, they know the
price they actually paid ... if the numbers don't add up that would seem to
be pretty easily detectable. But sure it's only for marketing.
On Tue, Jun 24, 2014 at 9:27 AM, Mike Hearn wrote:
> Wallets would then be able to persist this data to disk and compete on cool
> visualisations for how much money you saved over time.
heh, this is a cool idea.
It also seems like it would be subject to instant inflation, as it's
unprovable, an
I'd like to point out that there is quite a difference between "what
core nodes should be like" and "what the codebase core nodes are built
from must support".
Given sufficiently modularized code (which I think everyone seems to
be in favor of, regardless of the goals), you can likely build a
bina
Coinbase have started allowing merchants to set discounts for purchasing
with Bitcoin. Seeing an individual discount is not very motivating as they
tend to be small. Seeing them stack up over time can be more motivating
because it feels like free money. Many businesses exploit this effect with
loya
On 6/24/14, Tamas Blummer wrote:
> 3. Services e.g. exchange, payment processor This is where core +
> indexing server talking SPV to core is the right choice
I think this is my main question, what's the advantage of having the
processes talking via the p2p protocol instead of something more
Le 24/06/2014 11:44, Wladimir a écrit :
>> But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
>> work without any special servers, so why require a 'close binding' to
>> a trusted bitcoin core?
>
> To clarify (and not piss off ThomasV :-): I do not think the idea of
> having serv
On Tue, Jun 24, 2014 at 2:16 PM, Mike Hearn wrote:
> priority. So a single unified program that just figures it out automatically
> rather than expecting users to assemble a bag of parts seems a goal worth
> striving for.
As I've said before -- and I think we disagree here - I like moving
towards
>
> Although Pieter and I disagree with regard to issue #4351, we agree on
> wanting to keep (or at least making) bitcoind as lean as possible.
> Maintaining extra indices for others doesn't fit in there - that's
> also why the address index patch was not merged. An 'index node' could
> be a differ
I think there are three typical uses:
1. Building consensus on the block chain. This is what the core is for.
2. Single user wallets. This is where SPV alone is good.
3. Services e.g. exchange, payment processor This is where core + indexing
server talking SPV to core is the right choice
Re
On Tue, Jun 24, 2014 at 1:29 PM, Jorge Timón wrote:
> On 6/24/14, Mike Hearn wrote:
ou did want to separate the wallet code from the full node then that'd be
>> the way to do it.
>
> Exactly, this is part of my point, the qt-wallet does not support SPV
> operation at this point, and that complex
On 6/24/14, Mike Hearn wrote:
> bitcoind already supports SPV mode, that's how bitcoinj clients work.
> However the current wallet code doesn't use it, it integrates directly with
> the full mode main loop and doesn't talk P2P internally. Which is the fine
> and obvious way to implement the wallet
>
> From my experience the main thing people are missing with BitcoinJ is
> a quick and easy way to set up a wallet as a daemon, to use the
> functionality from non-java through RPC.
Yes. I'd love to have a mostly Core compatible JSON-RPC frontend. Most of
my current users are happy using it as a
> But IMO this is a passed stage. SPV wallets w/ Bloom filtering can
> work without any special servers, so why require a 'close binding' to
> a trusted bitcoin core?
To clarify (and not piss off ThomasV :-): I do not think the idea of
having servers with a reputation of their own is a passed stag
> The question is; what does this buy us, and is it worth the potentially huge
> amount of time it could take? My gut feeling is we have bigger fish to fry.
> There's plenty of work to do just on the core consensus code, making Bitcoin
> Core into a competitive wallet as well would be an additional
>
> So first bitcoind will support SPV mode then we separate the wallet?
> Are the core and the wallet share any code (say, the p2p messages via
> a sub-repo or something)?
>
bitcoind already supports SPV mode, that's how bitcoinj clients work.
However the current wallet code doesn't use it, it in
On Mon, Jun 23, 2014 at 10:15 PM, Jorge Timón wrote:
> On 6/23/14, Wladimir wrote:
>> It's least surprising if the wallet works as a SPV client by default.
>> Then, users can use it without first setting up a core. Thus the idea
>> would be to use P2P primarily.
>
> So first bitcoind will support
32 matches
Mail list logo
