<unnamed>

Public Key

npub1c56tk56u5846gc9tj6kcd886y9sztx6yrj24zhegrsv87qfs7nes834kvp

Profile Code

nprofile1qqsv2d9m2dw2r6ayvz4edtvxnnazzcp9ndzpe923tu5pcxrlqyc0fucpzpmhxue69uhkummnw3ezuamfdejskqeg7u

Publishing to

nostr.wine

Last Notes

2023-06-07 15:17:34 UTC

- reply

📅 Original date posted:2014-04-09
📝 Original message:On that note, I think we have every possibility to make desktop and mobile wallets mind-numbingly simple -- and perhaps even do one better. Is this now a community priority? If so, I would really appreciate some additional contributors to Hive!
https://github.com/hivewallet/hive-osx
https://github.com/hivewallet/hive-android
-wendell
hivewallet.com | twitter.com/hivewallet | pgp 0x8C498718
twitter.com/bitcoinbookclub | campbitcoin.hivewallet.com
On Apr 7, 2014, at 9:15 PM, Eric Martindale wrote:
> We need to make it so mind-numbingly simple to "run Bitcoin correctly" that the average user doesn't find reasons to do so in the course of normal use. Right now, Coinbase and Bitstamp are winning in the user experience battle, which technically endanger the user, and by proxy the Bitcoin network.
>
> Multi-sig as a default is a start. It won't succeed unless the user experience is simply better than trusted third parties, but we need to start the education process with the very basic fundamental: trusting a third-party with full access to your Bitcoin is just replacing one centralized banking system with another.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/0b52c0a2/attachment.sig>

2023-06-07 15:09:42 UTC

- reply

📅 Original date posted:2013-11-18
📝 Original message:We're with uBTC too. Been waiting for the signal to do this, let's do it right after the fee system is improved.
-wendell
grabhive.com | twitter.com/hivewallet | gpg: 6C0C9411
On Nov 15, 2013, at 6:03 AM, Jeff Garzik wrote:
> Go straight to uBTC. Humans and existing computer systems handle numbers to
> the left of the decimals just fine (HK Dollars, Yen). The opposite is
> untrue (QuickBooks really does not like 3+ decimal places).

2023-06-07 15:06:36 UTC

- reply

📅 Original date posted:2013-09-06
📝 Original message:Hi all,
We're thinking about ways of automatically exchanging contact details between wallets, in order to encourage the proliferation of identifiable names and photos rather than long and hard-to-verify addresses.
The simplest version goes like this:
2 BTC Bitcoin is sent to someone, and a data lookup hash is inserted into the transaction. When it arrives on the other end, it is indeed looked up, and instead of being presented with a dialogue that says "you received 2 BTC from 13Y94z43Nbbb6wevRyk82CeDoYQ5S28zmA", it's "You received 2 BTC from Frank Jones" including a nice photo.
Now. We can simply delete this data in reference to the transaction ID after it happens (or delete it after a time), but is there any more decentralized way to do it? I would prefer us to run no dedicated servers that would ever put us in a position of being coerced into giving data, or otherwise altering our system to store it.
Any thoughts about this?
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130906/6be1e4b2/attachment.sig>

2023-06-07 15:06:32 UTC

- reply

📅 Original date posted:2013-09-04
📝 Original message:Hi everyone,
Our OS X wallet "Hive" features an integrated application platform. We hope this will be a great way for folks new to Bitcoin to discover a variety of Bitcoin businesses, from exchanges, to merchants, to games. The applications are locally hosted HTML/JS, and generally feature the most stripped-down UIs possible. We display them in a mobile-proportioned WebKit frame inside of Hive itself. Transaction requests within apps trigger native Cocoa dialogue boxes and everything feels nicely integrated and secure.
Should Hive succeed in gaining a foothold, we hope that we may one day be able to sustain ourselves via an aggregate of very small fees on transactions within this app platform. We like the approach because it lets us stay focused on making Hive great, and keeping it free, but at the same time we recognize that it is a kind of obligatory middleman... With all that that implies? I'm not totally sure, and that's what the question is about.
Obviously there are a couple of brain-dead approaches: We could track what users do in the app, and send the business a bill (with blockchain proof, of course). Or, we could avoid troubling the business and have each user send a micro-transaction to some address of our choosing. The first one is messy and essentially makes us spyware. The second one is technically difficult, making a mess of transaction history, balances, and possibly in-app price listings. I'm not happy with either, but would lean towards the second one if I had to choose.
I'm not 100% sure if this is the appropriate venue for it, but before we make that decision, I wanted to state our intentions and see if I could get some fresher ideas in the door. We want to be as ethical and (ideally) decentralized as possible -- priorities #1 and #2 -- but are otherwise open-minded.
Some technical details for the curious:
1) Yes, everything will be free software under a GPL license -- including the app store and the apps themselves! That may seem to be risky given our proposed business model, but we are open-minded and think we very much welcome the 'competition' of a would-be forker / hope we can work together. ;-)
2) Although our BitcoinKit.framework supports both bitcoind and bitcoinj, we will be using bitcoinj with an integrated VM for the time being. The main draw is SPV, although to be honest we would prefer to support the network more via something like Peter Todd's partial UTXO sets idea (hint hint, anyone?).
We will be at the conference in Amsterdam on the 27th of this month if any of you want to meet and discuss.
Thanks for your time,
-wendell
grabhive.com | twitter.com/grabhive | gpg: 6C0C9411
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130904/3bbaa0d6/attachment.sig>

2023-06-07 15:05:14 UTC

- reply

📅 Original date posted:2013-07-24
📝 Original message:Forking for curiosity's sake:
Is there a substantial barrier to endian independence in the Bitcoin codebase?
-wendell
grabhive.com | twitter.com/grabhive
On Jul 24, 2013, at 3:45 AM, Douglas Huff wrote:
> The fact that you're even trying to package and/or at some point have packaged and shipped big endian binaries is straight up *NEGLIGENT.*

2023-06-07 15:04:45 UTC

- reply

📅 Original date posted:2013-07-17
📝 Original message:"The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop!"
Good lord Michael, I wish we had known about libcoin a month ago!
-wendell
grabhive.com | twitter.com/grabhive
On Jul 17, 2013, at 4:31 PM, Michael Gronager wrote:
> Hi Wendell,
>
> What Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with "master".
>
> Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.
>
> What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)
>
> Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/eb021d7c/attachment.sig>

2023-06-07 15:04:44 UTC

- reply

📅 Original date posted:2013-07-17
📝 Original message:Peter,
This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.
Will you implement this?
-wendell
grabhive.com | twitter.com/grabhive
On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:
> So what's useful about that? Basically it means your node starts with
> the same security level, and usefulness to the network, as a SPV node.
> But over time you keep downloading blocks as they are created, and with
> whatever bandwidth you have left (out of some user-configurable
> allocation) you download additional blocks going further and further
> back in time. Gradually your UTXO set becomes more complete, and over
> time you can verify a higher and higher % of all valid transactions.
> Eventually your node becomes a full node, but in the meantime it was
> still useful for the user, and still contributed to the network by
> relaying blocks and an increasingly large subset of all transactions.
> (optionally you can store a subset of the chain history too for other
> nodes to bootstrap from) You've also got better security because you
> *are* validating blocks, starting off incompletely, and increasingly
> completely until your finally validating fully. Privacy is improved, for
> both you and others, by mixing your transactions with others and adding
> to the overall anonymity set.
>
> In the future we'll have miners commit a hash of the UTXO set, and that
> gives us even more options to, for instance, have relayed transactions
> include proof that their inputs were valid, allowing all nodes to relay
> them safely.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/e78aceae/attachment.sig>

2023-06-07 15:04:41 UTC

- reply

📅 Original date posted:2013-07-16
📝 Original message:Hello everyone,
In the previous thread, I expressed interest in seeing an SPV bitcoind, further stating that I would fund such work. Mike Hearn followed up with some of Satoshi's old code for this, which is now quite broken. The offer and interest on my side still stand, as more diversity in SPV options seems like the right way to go.
Time-permitting, I would really appreciate feedback from knowledgable parties about the possible approaches to an SPV bitcoind. We at Hive ideally want to see something that could one be merge into master, rather than a fork.
-wendell
grabhive.com | twitter.com/grabhive

2023-06-07 15:04:36 UTC

- reply

📅 Original date posted:2013-07-15
📝 Original message:Hi Mike,
You are absolutely right about the synchronize time, it's one of our main frustration points right now and we clearly won't deliver the kind of user experience we want, without fixing this. Actually we were thinking of extending Jeff Garzik's picocoin as time permits, but the plan is far from concrete at the moment.
What you say about trans-piling bitcoinj is _really_ appealing. We discounted Java simply because an OS X JVM is no longer guaranteed, but otherwise bitcoinj is ideal for our purposes. How can we assist or otherwise accelerate such an effort?
-w
On Jul 15, 2013, at 3:19 PM, Mike Hearn wrote:
> That's great! I'm all for more wallets, especially user friendly UIs.
>
> However being based on bitcoind means it will take a very long time to synchronize for new users. We know a lot of users drop out. The best fix for this is SPV mode. Do you have any plans in this direction?
>
> So far, the only SPV mode implementation I know about is bitcoinj. I am experimenting with trans-piling bitcoinj to C++ to make it usable from Objective-C++ exactly with your use case in mind.

2023-06-07 15:04:35 UTC

- reply

📅 Original date posted:2013-07-15
📝 Original message:Hi devs,
Just wanted to cross-post this here since it seems very relevant.
We're launching BitcoinKit.framework, a Cocoa framework that allows developers to write Bitcoin wallet apps for Mac OS X. BitcoinKit uses bitcoind, and serves a small and tidy API for developer use. Support for other Bitcoin implementations (libcbitcoin, etc) is soon to follow.
BitcoinKit's first application is as the backbone of a new Mac wallet app called Hive, which will be released soon at www.grabhive.com.
Grab the source here:
https://github.com/grabhive/BitcoinKit
Support is available via GitHub issues and this Bitcointalk thread:
https://bitcointalk.org/index.php?topic=256583.msg2733523
A sample GUI app is also included:
http://imgur.com/FzqA00X
Cheers everyone!
-Wendell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130715/f4ae94ff/attachment.sig>