Btc Drak via bitcoin-dev writes:
> I think this thread has gotten to the stage where it should be moved
> to an issue on Github and not continue to CC the bitcoin-dev list (or
> any other list tbh).
Agreed. I couldn't see an issue, so I've opened one. Let's track this
there, please.
https://gi
On Thu, Oct 22, 2015 at 03:58:58PM -0500, Justus Ranvier via bitcoin-dev wrote:
> On 22/10/15 15:43, Luke Dashjr wrote:
> > BIPs should in general not be
> > designed around current software
>
> I strongly disagree with this statement.
>
> There is a version byte in the payment code specificatio
Benchmarks?
I cant imagine that's very fast.
On 10/22/2015 02:26 PM, Jeff Garzik via bitcoin-dev wrote:
> Here is the beginnings of an implementation to replace leveldb with
> sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite
>
> It builds, but still needs work before passing tests.
>
>
I have done a lot of recent work on local key value stores, mostly for a
java electrum server I am working on.
I'd suggest considering LMDB. One downside is that it is memory mapped so
32-bit systems that need over 2gb of storage are right out. Other than
that, it is quite fast and seems reliabl
On 22/10/15 16:47, Luke Dashjr wrote:
> Well, I strongly disagree with adopting the BIP as it stands.
That's fine. Nobody is required to adopt an informational BIP if they do
not wish to do so.
> No, those are not network-level changes. They are mere software changes that
> can be deployed along
On Thursday, October 22, 2015 8:58:58 PM Justus Ranvier wrote:
> I strongly disagree with this statement.
Well, I strongly disagree with adopting the BIP as it stands.
> Version 1 payment codes are designed to be deployable by wallet
> implementers today, without requiring them to wait on any net
Here is the beginnings of an implementation to replace leveldb with sqlite:
https://github.com/jgarzik/bitcoin/tree/2015_sqlite
It builds, but still needs work before passing tests.
It was noted that leveldb is unmaintained, and this is part of researching
alternatives that are maintained and rel
The consequence of previous ECDH address proposals "not designing around
current software" is a sustained ~70% of transactions reusing addresses, as
you saw in my Reddit post recently.
If you have a fear that an inferior proposal will gain popularity, you can
always propose a superior one. If it's
On 22/10/15 15:43, Luke Dashjr wrote:
> BIPs should in general not be
> designed around current software
I strongly disagree with this statement.
There is a version byte in the payment code specification for a reason.
Version 1 payment codes are designed to be deployable by wallet
implementers
On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> On 22/10/15 00:53, Luke Dashjr wrote:
> > Sorry for the late review. I'm concerned with the "notification address"
> > requirement, which entails address reuse and blockchain spam. Since it
> > entails address reuse, the recipient is
I think this thread has gotten to the stage where it should be moved
to an issue on Github and not continue to CC the bitcoin-dev list (or
any other list tbh).
On Thu, Oct 22, 2015 at 5:27 PM, Jonathan Toomim via bitcoin-dev
wrote:
> You may want to add a cron job to restart bitcoind every day or
You may want to add a cron job to restart bitcoind every day or two as a damage
control mechanism until we figure this out.
On Oct 22, 2015, at 9:06 AM, Multipool Admin wrote:
> This is a real issue. The bitcoind process is getting killed every few days
> when it reaches around 55gb of usage
This is a real issue. The bitcoind process is getting killed every few
days when it reaches around 55gb of usage on my server.
On Oct 21, 2015 12:29 AM, "Tom Zander via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Tuesday 20 Oct 2015 20:01:16 Jonathan Toomim wrote:
> > claim
On 22/10/15 00:53, Luke Dashjr wrote:
> Sorry for the late review. I'm concerned with the "notification address"
> requirement, which entails address reuse and blockchain spam. Since it
> entails
> address reuse, the recipient is forced to either leave them unspent forever
> (bloating the UTXO
Indeed the reason I got started with all of this is the use of normalized
transaction IDs within smart contracts with multiple signers. Sorry if I
was perceived as overselling it :-)
So to summarize the discussions that have been on-going here as well as in
the PR so far, most people seem to agree
On Thu, Oct 22, 2015 at 8:26 AM, Christian Decker via bitcoin-dev
wrote:
> Normalized transaction IDs do help in the case that the single signer wants
> to immediately follow up its transaction with another transaction spending
> the first one's change output, and it prevents any modification in t
On Thursday, October 22, 2015 8:26:58 AM Christian Decker wrote:
> I think the scenario of the single signer re-ordering the outputs and
> inputs and then re-signing the transaction is in the same category of
> simple double-spends. The signer could just as well sign a completely
> different transa
I think the scenario of the single signer re-ordering the outputs and
inputs and then re-signing the transaction is in the same category of
simple double-spends. The signer could just as well sign a completely
different transaction spending the same coins to somewhere else, so I don't
think there i
On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
Sorry for the late review. I'm concerned with the "notification address"
requirement, which entails address reuse and blockchain spam. Since it entail
19 matches
Mail list logo
