Kevin Greene [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-16 📝 Original message:Just thinking off the top ...
📅 Original date posted:2015-06-16
📝 Original message:Just thinking off the top of my head here:
What if SPV wallets were exempt from the fee? Only full nodes would pay
other full nodes when initially sync'ing the blockchain. Then as long as
you keep your full node running for a long period of time, you'll
eventually make back the cost you paid to sync initially. This at least
incentives full node operators to keep their node running for as long as
possible once started.
This still imposes a worse UX on casual users who want full node security,
but don't want to run a server 24/7 (or perhaps simply aren't aware that
they have to). These users will watch their balance wither away each time
they open their wallet, but it would be very difficult to explain to them
why that is happening. It would just be frustrating and confusing.
Also, what happens when a user runs Bitcoin-QT for the first time after
downloading it to try it out? They wouldn't be able to sync the blockchain.
Even if the wallet has a balance, how would the wallet be able to see that
it has UTXO's without the ability to sync with the network for free?
On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>
> On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
>> > Would SPV wallets have to pay to connect to the network too? From the
>> > user's perspective, it would be somewhat upsetting (and confusing) to
>> see
>> > your balance slowly draining every time you open your wallet app. It
>> would
>> > also tie up outputs every time you open up your wallet. You may go to
>> pay
>> > for something in a coffee shop, only to find that you can't spend your
>> > bitcoin because the wallet had to create a transaction to pay to sync
>> with
>> > the network.
>> >
>> > Also, users of centralized wallet services like Coinbase would not have
>> to
>> > pay that fee; but users of native wallets like breadwallet would have no
>> > such option. This incentivizes users to use centralized wallets.
>> >
>> > So this is kind of imposing a worse user experience on users who want to
>> > use bitcoin the "right" way. That doesn't seem like a good thing to me
>> :/
>>
>> SPV isn't the "right" way either ;)
>>
>
> Hah, fair enough, there is no such thing as the "right" way to do
> anything. But I still think punishing users who use SPV wallets is a
> less-than-ideal way to incentive people to run full nodes. Right now SPV is
> the best way that exists for mobile phones to participate in the network in
> a decentralized way. This proposal makes the user experience for mobile
> wallets a little more confusing and annoying.
>
>
>>
>> If you're running a full node (the real "right way"), you should be able
>> to
>> earn more bitcoins than you pay out.
>>
>> Luke
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/6dfa5428/attachment.html>
📝 Original message:Just thinking off the top of my head here:
What if SPV wallets were exempt from the fee? Only full nodes would pay
other full nodes when initially sync'ing the blockchain. Then as long as
you keep your full node running for a long period of time, you'll
eventually make back the cost you paid to sync initially. This at least
incentives full node operators to keep their node running for as long as
possible once started.
This still imposes a worse UX on casual users who want full node security,
but don't want to run a server 24/7 (or perhaps simply aren't aware that
they have to). These users will watch their balance wither away each time
they open their wallet, but it would be very difficult to explain to them
why that is happening. It would just be frustrating and confusing.
Also, what happens when a user runs Bitcoin-QT for the first time after
downloading it to try it out? They wouldn't be able to sync the blockchain.
Even if the wallet has a balance, how would the wallet be able to see that
it has UTXO's without the ability to sync with the network for free?
On Mon, Jun 15, 2015 at 8:49 PM, Kevin Greene <kgreenek at gmail.com> wrote:
>
>
> On Mon, Jun 15, 2015 at 8:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 16, 2015 3:30:44 AM Kevin Greene wrote:
>> > Would SPV wallets have to pay to connect to the network too? From the
>> > user's perspective, it would be somewhat upsetting (and confusing) to
>> see
>> > your balance slowly draining every time you open your wallet app. It
>> would
>> > also tie up outputs every time you open up your wallet. You may go to
>> pay
>> > for something in a coffee shop, only to find that you can't spend your
>> > bitcoin because the wallet had to create a transaction to pay to sync
>> with
>> > the network.
>> >
>> > Also, users of centralized wallet services like Coinbase would not have
>> to
>> > pay that fee; but users of native wallets like breadwallet would have no
>> > such option. This incentivizes users to use centralized wallets.
>> >
>> > So this is kind of imposing a worse user experience on users who want to
>> > use bitcoin the "right" way. That doesn't seem like a good thing to me
>> :/
>>
>> SPV isn't the "right" way either ;)
>>
>
> Hah, fair enough, there is no such thing as the "right" way to do
> anything. But I still think punishing users who use SPV wallets is a
> less-than-ideal way to incentive people to run full nodes. Right now SPV is
> the best way that exists for mobile phones to participate in the network in
> a decentralized way. This proposal makes the user experience for mobile
> wallets a little more confusing and annoying.
>
>
>>
>> If you're running a full node (the real "right way"), you should be able
>> to
>> earn more bitcoins than you pay out.
>>
>> Luke
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/6dfa5428/attachment.html>