<unnamed>

Public Key

npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs

Profile Code

nprofile1qqsx4349rx64fk8lwf4rq83a4mqtfz05gdunw787enrw57jndae4fugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsvcgtxr

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:18:02 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
> On 23.04.2014, at 21:55, Luke-Jr <luke at dashjr.org> wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any account other than 0. Remember addresses are used to receive
> > bitcoins; once the UTXOs are in the wallet, they are no longer
> > associated with the address or any other details of how they were
> > received.
>
> This is a bit idealistic.
> The wallet has to know how it got the UTXO in order to be able to spend it.
No it doesn't... Just the assigned scriptPubKey and secret(s) required to
satisfy it.

2023-06-07 15:18:01 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
> On 04/23/2014 10:41 PM, Luke-Jr wrote:
> > I don't see how. The user knows he has money in different subwallets. As
> > long as he has a way to specify which subwallet he is accessing in
> > single-subwallet clients, there shouldn't be a problem.
>
> Right. But these clients have no right to call themselves BIP64
> compatible then.
Then BIP 64 is pretty restrictive. Most end users really have no need for
subwallet support.

2023-06-07 15:18:01 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
> On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
> > Hopefully it would be clarified as only a MUST NOT do so silently...
> > "I have funds split across two wallets and it WONT LET ME SPEND THEM"
> > sounds like a terrible user experience. :)
>
> That is a subjective matter. To me it makes PERFECT SENSE that funds
> across accounts NEVER MIX. One can still send funds from one account to
> another and then perform another spend.
Only by crossing the blockchain unnecessarily.
> That's what I consider a consistent and thus GOOD user experience.
> What's the purpose of Accounts if wallet mixes coins among them anyway?
To keep balances separated. For example, I might have an account for each of
my children, move their allowance money to it every day/week (off-chain), and
they can spend only what they have in their account. Or an exchange might have
an account for each user's deposits. In neither case, would it make sense to
pay special attention to which UTXOs are consumed in transactions from any of
the account.
The only use case that requires tracking UTXOs per-account is when you want to
have multiple uncoordinated copies of the wallet in use at the same time, and
therefore need to immediately identify which account a transaction came from
based on the UTXOs it consumed - although even then, you could still mix funds
as long as you use only the first UTXO for tracking, so maybe there isn't even
a niche use case! In any case, Trezor, being a hardware wallet, should never
overlap with this niche...?
> I know it's not good to use classic bank accounts as analogy, but that's
> exactly how they work. Or have you every done ONE transaction from two
> bank accounts simultaneously?
Bad analogy. Banks *always* mix funds. You don't expect your bank wire to use
exactly the specific dollar bills you deposited, do you??
Luke

2023-06-07 15:17:59 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 9:06:26 PM Pavol Rusnak wrote:
> On 04/23/2014 10:54 PM, Pieter Wuille wrote:
> > Would you consider software which scans all accounts as specified by
> > BIP64, but has no user interface option to distinguish them in any
> > way, view them independently, and has no ability to keep the coins
> > apart... compatible with BIP64?
>
> This is not a desired behavior. Do you have any idea how to make it even
> more explicit in the spec? Currently we just have (in Account sectrion):
>
> "This level splits the key space into independent user identities, so
> the wallet never mixes the coins across different accounts."
>
>
> I would like to make it obvious from the spec that if you mix funds
> accross the accounts you are not doing a right thing and you are not
> compliant to the spec.
How do you get the more expected/usual behaviour of mixing funds between
accounts? Only a very niche user base needs funds isolated...
Luke

2023-06-07 15:17:58 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
> On 04/23/2014 10:32 PM, Luke-Jr wrote:
> > f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
> > instead of what has traditionally been called "account" in Bitcoin.
>
> Ah, okay. The last time I saw Bitcoin-qt it was still using independent
> addresses.
It is. Accounts have been a bitcoind feature since before 0.4.
> > In that case, single-subwallet wallet software probably needs to have the
> > user provide a subwallet number in addition to the seed.
>
> Which brings us back to my original complaint that the user can be
> confused because he doesn't see all his funds.
I don't see how. The user knows he has money in different subwallets. As long
as he has a way to specify which subwallet he is accessing in single-subwallet
clients, there shouldn't be a problem.
Luke

2023-06-07 15:17:57 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
> On 04/23/2014 10:09 PM, Luke-Jr wrote:
> > Scan all branches for UTXOs, then you have the balance for the wallet.
> > Account balances are metadata, so cannot be known from the seed alone.
> > If you want to have a way to restore accounts, you must define some more
> > detailed wallet file format (which could be built on top of this).
>
> I think one of the following is happening:
>
> a) you have not read the document
> b) you don't understand what accounts are, because you have not read
> the document
> c) you don't understand how restoring accounts work, because you
> have not read the document
> d) you don't understand that accounts funds are not meant to be mixed
> together, because you have not read the document
> e) I got your emails wrong because I am not a native speaker,
> but please read the the document ;-)
You missed one:
f) I missed the part where BIP 32 redefined "account" to mean "subwallet"
instead of what has traditionally been called "account" in Bitcoin.
:)
In that case, single-subwallet wallet software probably needs to have the user
provide a subwallet number in addition to the seed.
Luke

2023-06-07 15:17:57 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
> On 04/23/2014 10:01 PM, Luke-Jr wrote:
> > Yes, it should scan all possible (under the BIP-defined structure)
> > branches regardless of which features it supports.
>
> So you suggest to scan for accounts, show balances but don't allow user
> to spend them? Does not seem right to me.
Scan all branches for UTXOs, then you have the balance for the wallet. Account
balances are metadata, so cannot be known from the seed alone. If you want to
have a way to restore accounts, you must define some more detailed wallet file
format (which could be built on top of this).
On Wednesday, April 23, 2014 8:04:35 PM you wrote:
> On 23.04.2014, at 22:02, Luke-Jr <luke at dashjr.org> wrote:
> > On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
> >> The wallet has to know how it got the UTXO in order to be able to spend
> >> it.
> >
> > No it doesn't... Just the assigned scriptPubKey and secret(s) required to
> > satisfy it.
>
> To know the secret it needs to know which key coordinate to use that is
> logically the same as knowing the address it used to receive it.
Sure, it *knows* what address was used to receive it. But at the point it's a
UTXO, that address is no longer relevant.
Luke

2023-06-07 15:17:56 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
> On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr <luke at dashjr.org> wrote:
> > Any wallet should import all the coins just fine, it just wouldn't *use*
> > any
> > account other than 0. Remember addresses are used to receive bitcoins;
> > once the UTXOs are in the wallet, they are no longer associated with the
> > address or
> > any other details of how they were received.
>
> Wallet don't see UTXO until it scans all branches/accounts on HD node
> import.
Yes, it should scan all possible (under the BIP-defined structure) branches
regardless of which features it supports.
Luke

2023-06-07 15:17:56 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
> On 04/23/2014 09:44 PM, Luke-Jr wrote:
> > Why do clients need to use the features in BIP 64? If Electrum doesn't
> > want to use accounts, then it can just use account 0 for everything.
> > Refund chains are
>
> As Andreas wrote earlier in this thread: "There is no "bare minimum".
> Either you implement the "BIP" fully or not."
>
> What you suggest does not follow the principle of least surprise.
> Suppose user imports his BIP64 compatible wallet into Electrum, which
> claims it is BIP64 compatible, but actually implements just a subset of
> the spec (sticking account index to 0). The user now sees just a
> fraction of his coins and is puzzled.
Any wallet should import all the coins just fine, it just wouldn't *use* any
account other than 0. Remember addresses are used to receive bitcoins; once
the UTXOs are in the wallet, they are no longer associated with the address or
any other details of how they were received.
Luke

2023-06-07 15:17:55 UTC

- reply

📅 Original date posted:2014-04-23
📝 Original message:On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
> On 04/23/2014 09:00 PM, Tier Nolan wrote:
> > The point is to have a single system that is compatible over a large
> > number of systems.
>
> There is such system and it is called BIP32.
>
> On the other hand, in BIP64 we try to put a set of restrictions and
> rules on top of BIP32. There will always be some special usecases where
> BIP64 is not a good fit and there's no reason why you cannot use BIP32
> in a different manner using a different "purpose" field.
>
> Examples: Electrum does not want to use accounts and they start to use
> scheme m/65'/change/address (where change = 0 or 1). Or Andreas
> Schildbach wants to have refunds chain so he uses m/66'/chain/address
> (where chain = 0, 1 or 2).
>
> We wanted to find one good solution that fits all, but unfortunately it
> turned out everyone wants something a little bit different.
Why do clients need to use the features in BIP 64? If Electrum doesn't want to
use accounts, then it can just use account 0 for everything. Refund chains are
definitely a third case that should be added to the external and
internal/change address division... and a wallet not implementing refund
addresses would simply not use that chain.
Luke

2023-06-07 15:15:39 UTC

- reply

📅 Original date posted:2014-03-13
📝 Original message:On Thursday, March 13, 2014 4:37:02 PM slush wrote:
> Display based on locale.
Please don't bring locale into this. Bitcoin has always been intentionally
locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales
which swap the commas and periods). Localising display makes different locales
more or less incompatible at a human level, even if they use the same
blockchain.
Luke

2023-06-07 15:14:33 UTC

- reply

📅 Original date posted:2014-03-03
📝 Original message:On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote:
> Peter writes:
> > MtGox does host the bitcoin wiki, so yes, the funds probably do go to a
> > wallet held by MtGox in some fashion.
>
> The foolishness of sending a payment to a Mt. Gox-held wallet -- which is
> required to edit the wiki -- strikes me as a pressing issue. If I
> understand it correctly, this is a hard blocker that'll stop *all* new
> contributors. Further, I registered for the wiki and never got my
> confirmation email. Methinks the whole thing is broken. :(
We've been working on moving the wiki to new hosting, but it isn't a very high
priority (at least for MtGox). PM SomeoneWeird on IRC, as he is currently
handling manually approving new accounts for editing.
Luke

2023-06-07 15:13:23 UTC

- reply

📅 Original date posted:2014-02-12
📝 Original message:On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
> On 02/12/2014 08:44 AM, Alan Reiner wrote:
> > Changing the protocol to use these static IDs is a pretty fundamental
> > change that would never happen in Bitcoin. But they can still be
> > useful at the application level to mitigate these issues.
>
> Not to mention that it would be potentially very insecure to have
> consensus depend on data (scriptSigs) which are not hashed in the Merkle
> structure of a block.
>
> Not that anyone on this list has suggested such a change, but I've seen
> it raised multiple times on the forum....
This would be a problem if it was used in the merkle tree, but I'm pretty sure
using it for input selection would be pretty safe. One could even avoid the
index by simply using the hashScript as the sole input value; then even
CoinJoins would be safe without breaking chains of transactions (although this
would break address reuse entirely - but I don't see that as a problem in a
theoretical world). One of those things that an altcoin could improve upon
Bitcoin with... ;)

2023-06-07 15:12:21 UTC

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Monday, January 20, 2014 5:42:37 PM slush wrote:
> Hi all,
>
> during recent months we've reconsidered all comments which we received from
> the community about our BIP39 proposal and we tried to meet all
> requirements for such standard. Specifically the proposal now doesn't
> require any specific wordlist, so every client can use its very own list of
> preferred words. Generated mnemonic can be then applied to any other
> BIP39-compatible client. Please follow current draft at
> https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
How are they compatible if they could be using entirely different word lists??
> Because we're quickly moving towards release of Trezor firmware and we need
> to finalize this part of the firmware, we're asking for the last comments
> to current BIP39 draft.
Maybe I'm missing something, but shouldn't this be a client-side thing, not
implemented in the Trezor firmware at all?? O.o;;
Luke

2023-06-07 15:12:15 UTC

- reply

📅 Original date posted:2014-01-17
📝 Original message:On Friday, January 17, 2014 11:44:09 AM Wladimir wrote:
> On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr <luke at dashjr.org> wrote:
> > https://github.com/bitcoin/bitcoin/pulls/luke-jr
> >
> > These are pretty much all well-tested and stable for months now.
>
> #3242: Autoconf improvements needs rebase, and comment from jgarzik and me
> taken into account (about -enable-frontends=).
I'll try to get this done over the weekend.
> The others appear to be more controversial as they affect mining/consensus.
> I'd really like to see ACKs from more reviewers and testers there before
> merging.
Can you elaborate on this? I can see how Proposals might, if buggy, affect
consensus, but the rest shouldn't. I don't think there's anything
controversial in any of these (does someone disagree with CPFP?).
Luke

2023-06-07 15:12:14 UTC

- reply

📅 Original date posted:2014-01-16
📝 Original message:On Thursday, January 16, 2014 9:09:52 AM Wladimir wrote:
> Hello all,
>
> It has been way to long since last major release. Many improvements and new
> features have been added to master since, so we'd like to do a 0.9rc1
> release soon.
>
> The current aim is next month, February 2014.
>
> Of course there are still some open issues that need to be resolved before
> release
> https://github.com/bitcoin/bitcoin/issues?milestone=12&state=open
>
> If there is something else that you're working on and needs to end up in
> 0.9, or know of some nasty bug in master that should absolutely be solved
> first, please tell.
>
> Wladimir
https://github.com/bitcoin/bitcoin/pulls/luke-jr
These are pretty much all well-tested and stable for months now.

2023-06-07 15:10:30 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote:
> > 1) Who pays for it? Most obvious answer: Foundation. However there's
> > currently a fairly clear line between the foundation website and the
> > bitcoin.org <http://bitcoin.org> website. I personally am fine with the
> > bitcoin foundation funding the website, it's a lot closer to the bitcoin
> > community than github. But some people might care. So next step would be
> > to contact the Foundation board and see if they're willing to fund it.
>
> Actually I might find way to fund it. But I needed to have ACK &
> comments from developers before anything.
>
> ...
> > 4) Who admins it?
>
> Obviously, I thought it would be important that the server is owned by
> someone who can be trusted, with ssh access for all core developers.
>
> > 5) Who controls DNS for it?
>
> I'm not sure we'll get any change on this level. I have no idea if the
> domain is in good hands, except for the fact that nothing bad happened
> thus far. If anything, moving it to core developers (as intended when
> the domain was registered) would make more sense IMO. But again, is it
> possible, I don't know.
I don't think "core developers" should be directly in control here any more
than the Foundation should. Developers are good for development, not
necessarily web or server admin tasks. Only those directly involved in the
needed roles should have access IMO.
Luke

2023-06-07 15:10:26 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
> Otherwise, who has admin rights to the code projects
> (github/sourceforge/this mailing list)? Those people have proven they can
> be trusted so far.
Can someone explain how Sirius has proven the least bit untrustworthy?
Luke

2023-06-07 15:10:25 UTC

- reply

📅 Original date posted:2013-12-08
📝 Original message:On Sunday, December 08, 2013 9:03:38 AM Saïvann Carignan wrote:
> Binaries:
> Sourceforge is not encrypted, actually. Although binaries hosting /
> sharing could be a separate subject discussed later I think.
Encryption is useless here. We want everyone to be able to download Bitcoin
clients. Binaries on sourceforge are signed by multiple parties using gitian.
> Decentralization:
> So long as we actually use DNS, the website is centralized :( However,
> its content isn't (can be forked on GitHub), but regarding the domain
> name, there is not much we can do against this AFAIK.
So long as someone has root (or a user that can modify it), the website is
centralised. To really solve this, we would need a dedicated server that
accepts commands only when signed by N-of-M parties, inside a cage locked by
padlocks with keys held by independent parties, with a SSL certificate issued
by an authority that has multiple parties watch it every step of the way into
that server.
Luke

2023-06-07 15:09:39 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:On Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote:
> I really like the XBT idea. It makes a lot of sense to match the ISO
> currency symbol (though the ISO guys will have to adjust the way they've
> defined the "XBT"). And I do agree that going right to uBTC and
> skipping mBTC makes sense, too.
>
> I'd prefer them not be called "micro bitcoins." I really want to call
> them "microbes" ... but I'm not sure that has the right flavor for money
> transfer :) "Please give me 872 microbes". Perhaps we just call them
> "bits." Or even "micros" or "microbits". As I write this, I realize
> there's probably 872 threads on the forums about this already...
>
> But we would want to promote a consistent term, to avoid further
> confusion when people use different names for the new unit. It's not
> guaranteed to be successful, but if we pick a good name, and build it
> into the interface on the first release pushing the new unit, we have a
> chance to make the transition even easier.
As long as we're using SI units, IMO we should stick to SI. That means "micro-
bitcoins". *Informally/spoken*, an abbreviation like "mibicoins" might make
sense.
Luke

2023-06-07 15:09:36 UTC

- reply

📅 Original date posted:2013-11-15
📝 Original message:On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
> So "a payment clears after one confirmation, but you might want to wait
> until the payment has been confirmed n times".
> Then at least you are not using the same word for two different meanings
> and you're using stuff more familiar in popular lexicon.
> I dont think it's helpful for users if we use the word "blocks".
"Confirmations" in a numeric context isn't correct, though. We're using to it
because we've been using Bitcoin so long, but to the average person they would
expect it to mean something more than it is. If not referring to blocks, then
perhaps "witnessed N times"?
> For years, people had a problem with "email address", instead using "email
> number" but they got there eventually. Most people nowadays use "email
> address"
> So "payment address" or "bitcoin address" make better sense here when
> qualified as a "<foo> address" and not just an "address"
>
> You could also call it "payment id", but I dont think "invoice id" since
> no-one pays to an invoice id that's just a reference for a payment, not the
> destination.
>
> People are very familiar with Paypal these days, and are familiar with
> "paypal address" or their "paypal id" so again I think valid contenders are
> "bitcoin address" or "bitcoin id".
I think you might be demonstrating my point with regard to user confusion
here. Bitcoin addresses are *not* like email addresses, paypal ids, etc.
Bitcoin addresses aren't the destination - they're point to a destination (an
account in a wallet), but they also represent information such as who is
paying and what for - in other words, a specific invoice.
Luke

2023-06-07 15:09:34 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
> "key id" (thanks sipa).
>
> I know it's a more technical term, but that is rather the point. It
> was a fundamental error to call hashed-pubkeys "addresses" as people
> either associate this with "account" or physical addresses, which also
> rarely change.
>
> Security and privacy guarantees of the system are defeated when key
> pairs are reused. We should ideally adopt terminology that lead people
> to associations of ephemeral, temporary use. "key id" is at least
> neutral in this regard. Can anyone think of something better?
Keys are often reused, so not sure that conveys the single-use much better.
Reason I suggested invoice id is because nobody wants to pay the same invoice
twice.
Luke

2023-06-07 15:09:34 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote:
> On 11/14/13 3:01 PM, Luke-Jr wrote:
> > I think we all know the problems with the term "address". People
> > naturally compare it to postal addresses, email addresses, etc,
> > which operate fundamentally different. I suggest that we switch to
> > using "invoice id" to refer to what is now known as addresses, as
> > that seems to get the more natural understanding to people. On the
> > other hand, with the advent of the payment protocol, perhaps
> > address/invoice id use will die out soon?
> >
> > Thoughts?
>
> "key id" (thanks sipa).
To be clear, I wasn't suggesting renaming scriptPubKey, which sipa was talking
about with "key id"; just the destination-for-transaction presented to
end-users.

2023-06-07 15:09:33 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote:
> Obviously the answer is to just display all fees and trading rates as BTC
> or MBTC (.0000005 MBTC fee? how cheap!). On a more serious note, the
> transition should definitely be thought out well as it could be very
> damaging to have this confusion, but I would prefer to do it only once
> rather than twice.
I wonder if it might make sense to bundle some other terminology fixups at the
same time.
Right now, Bitcoin-Qt has been using the term "confirmations" (plural) to
refer to how many blocks deep a transaction is buried. We also use the term
"confirmation" to refer to the point where a transaction is accepted as paid.
IMO, the latter use makes sense, but the former leads to confusion especially
in light of scamcoins which abuse this confusion to claim they have "faster
confirmations", implying that the actual confirmation occurs faster when it
really doesn't. "5 blocks deep" may not be more clear to laymen, but at least
it makes it harder for people to confuse with actual confirmation.
I think we all know the problems with the term "address". People naturally
compare it to postal addresses, email addresses, etc, which operate
fundamentally different. I suggest that we switch to using "invoice id" to
refer to what is now known as addresses, as that seems to get the more natural
understanding to people. On the other hand, with the advent of the payment
protocol, perhaps address/invoice id use will die out soon?
Thoughts?
Luke

2023-06-07 15:09:30 UTC

- reply

📅 Original date posted:2013-11-14
📝 Original message:On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote:
> Would now be a good time to start thinking about changing the default
> display in the software. Perhaps initially it could be a dropdown display
> option, then at some point mbtc becomes the default?
There's already a dropdown display option...

2023-06-07 15:08:29 UTC

- reply

📅 Original date posted:2013-11-02
📝 Original message:On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
> I actually had a use case in my case where it was possible, and that was
> the check I used to get around it, just configured it so that I always
> generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
> It was either that or making sure I had no unspent outputs. The use case
> of doing it was laziness in just creating a single key.
Use cases mean an actual use, not mere laziness. Bitcoin as a system has
always required a unique EC key (and address) for each transaction.
Luke

2023-06-07 15:08:28 UTC

- reply

📅 Original date posted:2013-11-02
📝 Original message:On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote:
> This was one of my concerns when implementing a scheme where you sign a
> refund transaction before the original transaction is broadcast. I
> originally tried to pass a hash and have the server sign it. However, I
> had no way to know that what I was signing wasn't a transaction that was
> spending my coins! So I changed the code to require sending the full
> transaction, not just the hash. The other way to mitigate this is through
> not having any unspent outputs from this key.
Well, there's no use case to sign with an address that has already been sent
coins. The main problem with enforcing this is that you can't exactly stop
someone from sending to an "identity" address.
Luke

2023-06-07 15:08:25 UTC

- reply

📅 Original date posted:2013-11-02
📝 Original message:On Saturday, November 02, 2013 5:01:43 AM bitcoingrant at gmx.com wrote:
> In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are
> delighted to introduce the Message Signing based authentication method. In
> brief, the authentication work as follows:
> Server provides a token for the client to sign.
> client passes the signed message and the bitcoin address back to the
> server. server validates the message and honors the alias (optional) and
> bitcoin address as identification. http://forums.bitcoingrant.org/
> Above is a proof of concept forum that utilize this authentication method.
Congratulations! You've reinvented what Eligius and Bitcoin-OTC have been
doing for years! :)
There's no reason to ask the user to provide the address every time, though...
Luke

2023-06-07 15:08:15 UTC

- reply

📅 Original date posted:2013-10-28
📝 Original message:On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote:
> If anybody has strong feelings about what the reject categories should be,
> then please take the time to write a specific list, I can't read your
> mind....
It might make sense to use the rejection reasons from BIP 22 where applicable.
https://en.bitcoin.it/wiki/BIP_0022#Appendix:_Example_Rejection_Reasons
Luke

2023-06-07 15:08:09 UTC

- reply

📅 Original date posted:2013-10-27
📝 Original message:On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
> Currently bitcoinj gets a small but steady stream of bug reports of the form
> "my transaction did not propagate". It's flaky because the library picks one
> peer to send the transaction to, and then watches it propagate across the
> network. But if that selected peer refuses the tx for whatever reason, that
> propagation never comes, and there's currently no timeout to make it retry
> with a different node.
Sounds like the real bug is "BitcoinJ relies on good/servant behaviour from
other nodes". Don't assume your random node isn't hostile. Handling a peer
that doesn't relay your transaction for any reason (including if they lie to
you about having done so) should be expected behaviour.
Luke

2023-06-07 15:07:34 UTC

- reply

📅 Original date posted:2013-10-19
📝 Original message:On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
> I have a question regarding this part. I wrote a BIP for base 58 encoding /
> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
> to this list ourselves, but should contact you for a BIP number. I have
> contacted you a couple times on bitcointalk for a BIP number, but haven't
> received a response (or do those requests explicitly have to go to your
> email address)?
See BIP 1 for the process.. proposals go to this mailing list first.
Luke

2023-06-07 15:05:14 UTC

- reply

📅 Original date posted:2013-07-24
📝 Original message:On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote:
> Is there a substantial barrier to endian independence in the Bitcoin
> codebase?
I got the obvious stuff ('endian' branch in my repo), but it still didn't work
when I moved on. I haven't had time to try to figure out why not yet.
Luke

2023-06-07 15:03:57 UTC

- reply

📅 Original date posted:2013-06-27
📝 Original message:On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
> * Very real possibility of an overall net reduction of full nodes on P2P
> network
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
MultiBit node. :/
Jim, will MultiBit be adding p2p listening support?
> I'm sure others can come up with a few more.
Possibly against: Does MultiBit still promote Bitcoin misunderstandings with
misinformation like "from" addresses? (my apologies if I am remembering a
different client)

2023-06-07 15:02:42 UTC

- reply

📅 Original date posted:2013-06-06
📝 Original message:On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
> scriptPubKey: <data> OP_TRUE
>
> ...
> Along with that change anyone-can-spend outputs should be make IsStandard()
> so they will be relayed.
Data does not belong in the blockchain. People running nodes have all
implicitly agreed to store the blocks for financial purposes, and storing data
is a violation of that social contract. Proof-of-stake may be arguably
financial, but I'm sure there must be a way to do it without spamming people
against their consent.
> The alternative is sacrifices to unspendable outputs, which is very
> undesirable compared to sending the money to miners to further
> strengthen the security of the network.
The alternative is to make other standard outputs unable to store data as
well.
Luke

2023-06-07 15:02:27 UTC

- reply

📅 Original date posted:2013-05-25
📝 Original message:On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
> It might be an idea to have 'rule change' fixes and 'bug fix' releases go
> out separately
Bitcoin is a consensus system. You can't run clients with different rules on
the same blockchain/network - it just won't work! Maybe we're now talking
about mere client default policies? In which case, you should be able to
configure previous behaviour...
If you want just bug fixes and rule changes, without policy default changes,
new features, etc, you can use the 0.4.x - 0.7.x backports. But be advised
these are short-term solutions and won't be maintained forever - so you really
should try to get the behaviour you want from the current release. If you
can't for some reason, please do report a bug explaining what it is the older
version was capable of that the new one isn't!
Luke

2023-06-07 11:39:20 UTC

- reply

📅 Original date posted:2013-03-15
📝 Original message:On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
> On Mar 13, 2013, at 8:18 PM, Cameron Garnham <da2ce7 at gmail.com> wrote:
> > For me, everyone signed up to bitcoin thinking that there was a 1MB /
> > block limit. The lock limits were unexpected, and could be considered
> > extremely uncontroversial to remove.
>
> This. Software behavior which is not described by the source code should
> not be considered an integral part of the rule set. Any influence of
> external libraries on the consensus mechanism is unacceptable.
Note that the lock limits were explicitly set in the bitcoind source code.

2023-06-07 11:39:01 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote:
> On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote:
> > Here's a simple proposal to start discussion from...
>
> It seems to me that the biggest failure was not the development of two
> chains, but the assurance to users (by the client) that their transactions
> were confirmed.
These are both the same thing.
Luke

2023-06-07 11:38:55 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 5:41:29 PM you wrote:
> I'm not sure I understand the need for hard forks. We can get through this
> crisis by mining pool collusion to prevent forking blocks until there is
> widespread adoption of patched clients.
Anything requiring widespread adoption of patched clients *is by definition* a
hard fork.
> Proposal:
>
> 1) Patch the pre-0.8 branches to support an increased lock count, whatever
> number is required to make sure that this problem never shows up again at
> the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
This is a hard fork.
The only way to avoid a hard fork is to apply the existing lock limit to all
clients forever. That would be fine, except that pre-0.8 clients cannot reorg
N blocks without dividing that limit by (N * 2) + 1; that leaves us with the
limit of around 1000 locks per block on average. Each transaction uses at
least 3 locks on average (many times more). So about 300 transactions per
block. This is a much smaller limit than the 1 MB we've been assuming is the
bottleneck so far, and the need to increase it is much more urgent - as Pieter
noted on IRC, we are probably already using more than that even ignoring DP
spam. The only reason pre-0.8 clients have survived as well as they have thus
far is because the blockchain has managed to avoid very deep reorgs.
Luke

2023-06-07 11:38:52 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
> Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
> which all verifying implementations must adhere to. I'm suggesting that we
> instead change the old codebase to do what we expected it to do all along
> (what 0.8 does and what every other verifying implementation does), and
> through miner collusion buy ourselves enough time for people to update
> their own installations.
Curiously enough, at least MtGox's custom implementation stuck with the
canonical blockchain despite 0.8's accidental rule change.
> I know there's people here who will jump in saying that the bitcoin
> protocol is the behavior of the Satoshi client, period. But which Satoshi
> client? 0.7 or 0.8? How do you resolve that without being arbitrary? And
> regardless, we are moving very quickly towards a multi-client future. This
> problem is very clearly a *bug* in the old codebase. So let's be forward
> thinking and do what we would do in any other situation: fix the bug,
> responsibly notify people and give them time to react, then move on. Let's
> not codify the bug in the protocol.
No, if any other client released diverged from the consensus of all
past/existing clients, we would do the same thing: call it a formerly unknown
protocol rule, that this new client has a bug implementing, and be done with
it.
The only reason this particular issue needs special treatment is because the
implications of the new rule mean that we're up against a hard limit in the
protocol today rather than 2 years from now.
Luke

2023-06-07 11:38:26 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:On Wednesday, March 13, 2013 3:18:36 PM Gregory Maxwell wrote:
> On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd <pete at petertodd.org> wrote:
> > If we're going to consider doing this, at minimum we need to also
>
> I beg people to not derail discussion about fixing things with
> discussion of other controversial changes.
I figured 2 MB in 2-3 years was fairly uncontroversial.
If not, let's scrap that idea for now.
> Luke-jr, any chance in getting you to revise your proposal to narrow
> the scope to things that don't need serious debate?
It was a one-time "start the conversation" proposal.
I expect what we end up going with may be substantially different.
Luke

2023-06-07 11:38:13 UTC

- reply

📅 Original date posted:2013-03-13
📝 Original message:Here's a simple proposal to start discussion from...
BEFORE block 262144:
- Never make a block that, combined with the previous 4 blocks, results in
over 4500 transaction modifications.
- Reject any block that includes more than 4500 transaction modifications on
its own (slight soft-fork)
- (these rules should make older clients safe under most circumstances)
FROM block 262144 to block 393216 (hard fork #1):
- Never make, and reject any block that includes more than 24391 transaction
modifications on its own (this *should* be equivalent to 1 MB)
- (this rules can make older client backports safe unless a reorg is more than
6 blocks deep)
FROM block 393216 onward (hard fork #2):
- Never make, and reject any block that includes more than 48781 transaction
modifications on its own (this *should* be equivalent to 2 MB)
- Accept blocks up to 2 MB in data size
- Discontinue support for clients prior to 0.8.1
I intentionally set the block numbers conservatively to try to account for the
yet-unseen ASIC upgrade.
Thoughts?

2023-06-07 11:36:10 UTC

- reply

📅 Original date posted:2013-03-11
📝 Original message:On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
> From: "Rune K. Svendsen" <runesvend at gmail.com>
>
> On the Main tab in the Options dialog, it previously said a minimum
> fee of 0.01 is recommended. This amounts to about $0.50 at today's
> price. Change this to 0.001 to be more sensible. We could even go
> lower, perhaps.
Please use GitHub pull requests (or at least publish a git repository) rather
than mailing patches..
I'd suggest two commits for this:
1. Move the recommended fee outside the translatable string (bonus points to
format it using the user's preferred unit)
2. Change the recommended fee in one place
Whether the recommended fee *should* be changed or not, I have no opinion on.
Eligius uses a lower minimum fee, but I believe most pools/miners will treat
anything under 0.01 BTC as if it were no fee at all...
Luke

2023-06-07 11:31:45 UTC

- reply

📅 Original date posted:2013-02-08
📝 Original message:On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote:
> Windows builds are varying with every compile, and I think I finally
> figured out why: we are not passing the -frandom-seed flag down into
> the leveldb build (I used objdump to dump two different binaries, and
> they differed only in the names of some leveldb objects). That should
> be an easy makefile fix.
FWIW, this should be already mostly-fixed in pull #2243 I submitted 9 days
ago... only thing not in that pull is changing gitian to use the standard
CXXFLAGS rather than our non-standard DEBUGFLAGS (whether DEBUGFLAGS should be
propagated to LevelDB or not is another conversation I guess).
Luke

2023-06-07 11:31:23 UTC

- reply

📅 Original date posted:2013-02-09
📝 Original message:On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
> > Why don't you use namecoin or another alt-chain for this?
>
> Because namcoin tries to solve a different problem, DNS, whereas I want
> to establish an identity for a payment protocol.
What is the technical difference here? Namecoin ties names to data; DNS is a
specific namespace in it. There is no reason I know of that this identity
stuff cannot be a new namespace.
> You can argue that alt-chains _can_ be as strong as bitcoin, but they
> don't _have to_ be. There is no guarantee how many people will
> cross-mine.
This is true of namecoin, but it does not have to be true of new merged-mined
data. You could very well require the Bitcoin proof-of-work to be valid and
the master header to be in the Bitcoin blockchain.
> The alt-chain could even disappear at some point. If at some point your alt-
> chain is no longer being worked on, then how do you prove that some old
> bitcoin transaction went to an address for which there was a valid
> id/certificate at the time of sending? If the certificate is based inside
> bitcoin's blockchain then you will have a proof for the correct destinations
> of all your old transactions as long as bitcoin exists.
Yes, if people stop using your system, it won't work. Consider that a "this
idea failed" scenario, where it doesn't matter.
Luke

2023-06-07 10:40:19 UTC

- reply

📅 Original date posted:2012-11-26
📝 Original message:On Tuesday, November 27, 2012 12:02:42 AM Rick Wesson wrote:
> Another nifty thing is that it can associate a cert to a domain and a
> payment address, if one were to put said address in the DNS :)
>
> Now I am sure the majority of the bitcoin user-base desires anonymity,
> but as a merchant I would like to be knowable and wouldn't mind it if
> my identity and those of my transactions were "known" and associated
> both with my domains and x.509 cert. In most commercial transactions
> (which include many of those that leverage invoices) identity is
> important, at least for the merchant.
Anonymity isn't a feature we claim to have, nor a goal of the project for the
most part. Using a single Bitcoin address has many problems besides non-
anonymity: your customers are denied basic privacy and there is no good way to
guarantee the user who says he paid you really did (since transaction ids are
public record, anyone can claim they sent it).
In short, it is for the most part considered a rule to always use a unique
address per transaction or at least per customer.
Luke

2023-06-07 10:40:06 UTC

- reply

📅 Original date posted:2012-11-26
📝 Original message:On Tuesday, November 27, 2012 12:16:07 AM Gregory Maxwell wrote:
> On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr <luke at dashjr.org> wrote:
> > On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> >> Would you find it acceptable if something supported a static whitelist
> >> plus a OS provided list minus a user configured blacklist and the
> >> ability for sophisticated users to disable the whitelist?
> >
> > How is this whitelist any different from the list of CAs included by
> > default with every OS?
>
> Because the list is not identical (and of course, couldn't be without
> centralizing control of all OSes :P ) meaning that the software has to
> be setup in a way where false-positive authentication failures are a
> common thing (terrible for user security) or merchants have to waste a
> bunch of time, probably unsuccessfully, figuring out what certs work
> sufficiently 'everwhere' and likely end up handing over extortion
> level fees to the most well established CAs that happen to be included
> on the oldest and most obscure things.
There is a common subset of CAs which are included in all OSs.
That's the "whitelist equivalent". We or someone else could even setup a list
of these common CAs for merchants if that is needed.
The fees CAs charge for certs is a flaw in the CA model in general, I don't
see that it's important for us to solve it.

2023-06-07 10:39:47 UTC

- reply

📅 Original date posted:2012-11-26
📝 Original message:On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
> Obviously the state of the world with browsers is not that good... but
> in our own UAs we can do better and get closer to that.
This effectively centralizes Bitcoin (at least in the eyes of many) and even
if each competing client had their own list, you'd be back to the original
"problem" of not being sure your CA is on all lists.
> Would you find it acceptable if something supported a static whitelist
> plus a OS provided list minus a user configured blacklist and the
> ability for sophisticated users to disable the whitelist?
How is this whitelist any different from the list of CAs included by default
with every OS?

2023-06-07 10:39:37 UTC

- reply

📅 Original date posted:2012-11-26
📝 Original message:On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote:
> They could be included as well of course, but from a seller
> perspective the most important thing is consistency. You have to be
> able to predict what CAs the user has, otherwise your invoice would
> appear in the UI as unverified and is subject to manipulation by
> viruses, etc.
That's expected behaviour - except it's mainly be manipulated by *users*, not
viruses (which can just as easily manipulate whatever custom cert store we
use). If I don't trust Joe's certs, I don't want Bitcoin overriding that no
matter who Joe is or what connections he has.
> So using the OS cert store would effectively restrict merchants to the
> intersection of what ships in all the operating systems their users
> use, which could be unnecessarily restrictive. As far as I know, every
> browser has its own cert store for that reason.
Browsers with this bug are not relevant IMO.

2023-06-07 10:39:31 UTC

- reply

📅 Original date posted:2012-11-26
📝 Original message:On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote:
> Minor caveat, IMHO we should support all CAs used by the popular
> browsers.
I would prefer using the user-accepted certs at the operating system level...

2023-06-07 10:29:52 UTC

- reply

📅 Original date posted:2012-09-10
📝 Original message:On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote:
> Here is a BIP draft for improving the block relaying and validation so that
> it can be done in parallel and so that redundancy can be removed. This
> becomes more beneficial the larger the block sizes are.
>
> https://en.bitcoin.it/wiki/User:MatthewLM/ImprovedBlockRelayingProposal
Most of the problem with block propagation lies in implementation, not
protocol... Distributing missing transaction on an as-needed basis is a
possible improvement at the protocol level, but there hasn't (AFAIK) been any
research into whether the little benefit outweighs the cost yet. In any case,
I don't see why 6 new messages are needed instead of simply adding a single
new type to getinv?

2023-06-07 10:21:10 UTC

- reply

📅 Original date posted:2012-07-09
📝 Original message:FWIW, all this argumenting is why my original suggestion for a Clients list
focussed on objective information in alphabetical order.

2023-06-07 10:09:45 UTC

- reply

📅 Original date posted:2012-05-24
📝 Original message:On Friday, May 25, 2012 12:51:09 AM Jeff Garzik wrote:
> On Thu, May 24, 2012 at 8:45 PM, Luke-Jr <luke at dashjr.org> wrote:
> > On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> >> Comments? It wouldn't be a problem if these no-TX blocks were not
> >> already getting frequent (1 in 20).
> >
> > FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1
> > in 10) of 1-txn blocks is not actually unreasonable. This also means
> > these 1-txn mined blocks are not necessarily harming Bitcoin
> > intentionally. Anyone care to figure out the math for how fast miners
> > need to finish processing transactions to reduce the number of 1txn
> > blocks?
>
> Look at the time since last block, and correlate with the number of
> non-spam TX's in the memory pool at the time. It is obvious which
> ones are quick blocks (<60 seconds since last block, no big deal) and
> which ones are the lazy miners (> 120 seconds since last block).
Block times are not accurate enough for that.

2023-06-07 10:09:39 UTC

- reply

📅 Original date posted:2012-05-24
📝 Original message:On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> Comments? It wouldn't be a problem if these no-TX blocks were not
> already getting frequent (1 in 20).
FWIW, based on statistics for Eligius's past 100 blocks, it seems 10% (1 in
10) of 1-txn blocks is not actually unreasonable. This also means these 1-txn
mined blocks are not necessarily harming Bitcoin intentionally. Anyone care to
figure out the math for how fast miners need to finish processing transactions
to reduce the number of 1txn blocks?

2023-06-07 10:09:32 UTC

- reply

📅 Original date posted:2012-05-24
📝 Original message:On Thursday, May 24, 2012 4:33:12 PM Jeff Garzik wrote:
> There appears to be some non-trivial mining power devoted to mining
> empty blocks. Even with satoshi's key observation -- hash a fixed
> 80-byte header, not the entire block -- some miners still find it
> easier to mine empty blocks, rather than watch the network for new
> transactions.
>
> Therefore I was wondering what people thought about a client
> implementation change:
>
> - Do not store or relay empty blocks, if time since last block < X
> (where X = 60 minutes, perhaps)
>
> or even stronger,
>
> - Ensure latest block includes at least X percent of mempool
> unconfirmed TXs
These are problematic for legitimate miners:
1) The freedom to reject transactions based on fees or spam filters, is
severely restricted. As mentioned in other replies, this is an important point
of Bitcoin's design.
1b) This punishes miners with superior transaction spam filtering. As with all
spam filtering, it is often an "arms race" and therefore the filter rules must
be kept private by the miners, and therefore cannot be disclosed for the
validating clients to take into consideration.
2) For a few seconds after a new block is received, the new transaction merkle
root(s) are not finished calculating. During this time, most miners are
working on "blank" blocks with the new previousblockhash but no transactions.
If those blocks are ignored, miners are forced to shutdown mining during this
time.
3) As you mentioned, illegitimate miners can easily workaround these
restrictions (even the second one, by flooding the network with their own
transactions). This puts the legitimate miners at a disadvantage in their own
search for valid blocks, unless they also come up with counter-measures
themselves.
The argument that these are not rule changes is flawed:
1) As of right now, 99% of the network runs a single client. Anything this
client rejects does de facto become a rule change.
2) Even if there were a diverse ecosystem of clients in place, discouragement
rules that potentially affect legitimate miners significantly mess with the
odds of finding a block.
3) If legitimate miners do not adopt counter-rules to bypass these new
restrictions, the illegitimate miners are left with an even larger percentage
of blocks found.
To summarize, I believe such a change as proposed would be very harmful to
Bitcoin.
Luke

2023-06-07 10:06:51 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:On Wednesday, May 02, 2012 3:34:35 PM Gary Rowe wrote:
> Bitcoin-Qt
> * Developed in C
This is far less relevant than license...
> Armory
> * Requires the entire blockchain
> * Dependent client of Bitcoin-Qt
Or bitcoind?
> Electrum
> * Dependent client of Bitcoin-Qt (on server)
Dependent on centralized server, not any particular client
> Bitcoin Wallet (Android client)
There are multiple Android clients. There is (or was) an OS selection to the
left of the client choices...
On Wednesday, May 02, 2012 3:43:23 PM Alan Reiner wrote:
> I'm not sure what "designed for occasional use" means. Many users of
> other clients use them exclusively without touching other clients. Armory
> is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
> I'm sure the other clients are the same.
Pretty sure it means "not running continuously".
> Btw, Armory now has full installers for both Windows and Linux
> (Ubuntu/Debian), with uninstallers and automatic URI registration
Would be awesome if it took after Spesmilo and managed bitcoind itself in the
background...

2023-06-07 10:06:14 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:On Wednesday, May 02, 2012 12:21:13 PM grarpamp wrote:
> Can someone also please set the reply-to header
> for these lists. It's really annoying to hit reply and
> not have the list address show up. Thanks :)
Try "Reply to All"

2023-06-07 10:06:08 UTC

- reply

📅 Original date posted:2012-05-02
📝 Original message:On Wednesday, May 02, 2012 9:22:42 AM Mike Hearn wrote:
> The original software written by Satoshi Nakamoto, the project's founder.
This is just wrong. While Bitcoin-Qt is by far the best client, it is
Wladimir's, not Satoshi's.
> If your computer is low powered or you aren't willing to tolerate a 24-hour+
> initial start time, you should consider other clients.
Isn't this down to only a few hours now?
> Armory was partly funded by a community donation drive which raised over
> $4000.
I don't see this as relevant. Every client has been partly funded by
donations, anyway.

2023-06-07 03:09:39 UTC

- reply

📅 Original date posted:2012-02-28
📝 Original message:On Tuesday, February 28, 2012 11:48:39 AM Pieter Wuille wrote:
> A simple way to fix this, is adding an extra protocol rule[1]:
>
> Do not allow blocks to contain a transaction whose hash is equal to
> that of a former transaction which has not yet been completely spent.
>
> I've written about it in BIP30[2]. There is a patch for the reference
> client, which has been tested and verified to make the attack
> impossible.
Has it been verified to make even rocconor's complicated transaction-based
version impossible?
> The purpose of this mail is asking for support for adding this rule to
> the protocol rules. If there is consensus this rule is the solution, I
> hope pools and miners can agree to update their nodes without lengthy
> coinbase-flagging procedure that would only delay a solution. So, who
> is in favor?
Can we do this in two steps? First, prefer blocks which don't break the rule;
once 55%+ are confirmed to have upgraded, then it is safe to treat it as a
hard rule.

2023-06-07 03:08:15 UTC

- reply

📅 Original date posted:2012-02-20
📝 Original message:On Monday, February 20, 2012 6:17:01 AM Michael Grønager wrote:
> Just posted this on the wiki BIP-13 discussion - should I make it into a
> BIP of its own ?
If you must. However, BIP 13 has been pretty much undisputed, and only held
back by BIP 16/17 so far...
> The "version" portion of the address has so far been labeled "network id",
> and indicates from which network and which chain the address can be used
> for.
Where do you see this? It has always been "version" as far as I am aware, and
we discussed formalizing the details of the bits in it a few months back.
In any case, it was certainly originally intended as "version" as can be
observed in Satoshi's reference implementation.

2023-06-07 03:03:57 UTC

- reply

2023-06-07 03:03:54 UTC

- reply

📅 Original date posted:2012-02-01
📝 Original message:On Wednesday, February 01, 2012 11:20:22 AM Michael Grønager wrote:
> OK - from your path it looks like linux. What version of Boost do you use.
> I require 1.47 or 1.48. - I will change that, but it is quite handy for
> signal_sets - will make an alternative scheme though.
Boost 1.46.1 is the latest stable on Gentoo.
> And, as for 0.4 vs 0.5 - I have tried to follow the changes, which were
> mostly (?) related to the integration of the qt client, which would have
> to be re-done anyway. Then there were some deadlock fixes, that I don't
> need ;). A fix for a special attack, that I have included. But I will go
> over everything again.
Perhaps it would be easier to merge with the latest 0.4.x branch:
git://gitorious.org/+bitcoin-stable-developers/bitcoin/bitcoind-stable.git

2023-06-07 03:03:41 UTC

- reply

📅 Original date posted:2012-02-01
📝 Original message:On Wednesday, February 01, 2012 10:58:28 AM Michael Grønager wrote:
> Your CMake cannot find boost - use ccmake or cmake-gui to help it with the
> location.
I didn't see anything useful in ccmake. Boost is in the standard locations
(/usr/include/boost/ and /usr/lib/libboost*
> Btw what platform are you using ?
Gentoo

2023-06-07 03:03:35 UTC

- reply

📅 Original date posted:2012-02-01
📝 Original message:On Wednesday, February 01, 2012 9:18:32 AM Michael Grønager wrote:
> libcoin is now in a state ready for its first release, which I would like
> to share with you!
Looks interesting. However, it doesn't configure for me:
http://paste.pocoo.org/show/544135/
I noticed it's forked from bitcoind 0.4.x. Do you plan to merge up to 0.5.x?
Luke

2023-06-07 02:56:24 UTC

- reply

📅 Original date posted:2012-01-17
📝 Original message:On Monday, January 16, 2012 7:46:39 PM Alan Reiner wrote:
> In response to Jeff and Luke-Jr, I don't see how this is /just any other
> poltical issue/. It strikes at the heart of everything Bitcoin is about.
Sorry, Bitcoin is not about the same thing to everyone. For me, Bitcoin is
about one thing: providing a monetary system for the Tonal number system.
Otherwise, it would be merely an interesting project I have no real concern
with. To assume everyone has the same interests is a sure-fire way to prevent
widescale adoption. If you want Bitcoin to succeed, don't try to impose a
single purpose/"about" on everyone using it (which a "blackout" would do).
> Barring Bitcoin-specific legislation, I don't see how any legislation
> could be more relevant to Bitcoin and the community around it.
Bitcoin is an innovative new currency. How is a bill on internet censorship
(which is badly needed, even if not in the form of SOPA/PIPA) directly
relevant? I don't think it is.

2023-06-07 02:55:58 UTC

- reply

📅 Original date posted:2012-01-15
📝 Original message:On Sunday, January 15, 2012 5:37:05 PM Jeff Garzik wrote:
> There are always issues that raise ire and moral outrage. I would
> rather that bitcoin.org stay apolitical -- our users will appreciate
> this in the long run.
I agree (with the conclusion). There are much more important and urgent
problems than SOPA/PIPA that we'd need to constantly 'blackout' if we did it
over every single problem.

2023-06-07 02:49:28 UTC

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Proposal to require compact public key addresses with version 21 (starting with '4') and length 33 for better efficiency. No apparent issues.
📝 Original message:I propose that full public key addresses be required to be "compact" (length
33), and use version 21 (begins with '4', and is redundant with ver 20 for 20-
byte data). Any reason this wouldn't be workable?

2023-06-07 02:49:15 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: Jorge Timón proposes putting the whole public key in each output for efficiency in the blockchain, but favors sipa's key extraction solution.
📝 Original message:On Sunday, December 18, 2011 9:28:36 AM Jorge Timón wrote:
> Back on topic, is actually putting the whole pub key in each output
> what you're proposing?
Yes, just like is already done for generation, since it is more efficient
*overall* for the block chain. sipa's key extraction is a MUCH better
solution, however, so if we can get that without a block chain fork, I'm
inclined to favour it.

2023-06-07 02:49:09 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: "Green addresses" are problematic and should not be encouraged, according to a professional's opinion.
📝 Original message:On Sunday, December 18, 2011 7:15:26 AM Jorge Timón wrote:
> I'm just saying is useful for the "green address" particular case.
"Green addresses" are also a broken-by-design feature and should be
discouraged.

2023-06-07 02:48:53 UTC

- reply

📅 Original date posted:2011-12-17
🗒️ Summary of this message: Standardizing and supporting public key addresses is better for large QR codes, despite their length being less ideal for humans.
📝 Original message:IMO, we should standardize and support public key addresses. While not ideal
for humans, because of their length, it's a better fit for large QR Codes IMO.

2023-06-07 02:48:20 UTC

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Experts suggest that paying to a domain name should be done through HTTPS queries to avoid security risks, and a fixed address can be used for payments.
📝 Original message:On Tuesday, December 13, 2011 8:06:15 AM Gavin Andresen wrote:
> I agree with Mike Hearn and Christian Decker-- paying to
> 'somebody at foo.com' should become, behind the scenes, a HTTPS query to
> https://foo.com/something. If you just want to (say) donate to
> eff.org, then paying to '@eff.org' aught to work nicely.
Seems like introducing a gaping security risk to me.
> It seems to me that if it was DNS-based, the address should be
> something like 'somebody.bitcoin.foo.com'. But I think it is unlikely
> people will setup and run a custom DNS server just to support bitcoin
> payments.
Could always use a fixed address and email somebody at foo.com a signed message.

2023-06-07 02:46:50 UTC

- reply

📅 Original date posted:2011-12-14
🗒️ Summary of this message: Rick Wesson suggests using secured zones to publish TXT records for digital currencies, specifically proposing the format _btc.<lhs>.<rhs> for Bitcoin. However, using DNS for transactions may be challenging.
📝 Original message:On Wednesday, December 14, 2011 6:02:25 PM Rick Wesson wrote:
> I also am largely in favor of using secured zones to publish TXT
> records to digital currencies. I've been thinking mainly about TXT
> using the following format for bitcoin.
>
> _btc.<lhs>.<rhs>
Don't confuse BTC (Bitcoin unit) with BC (Bitcoin in general / protocol)...
The hard part of using DNS will be sticking to the standard good practice of
using a new address for every transaction.

2023-06-07 02:46:34 UTC

- reply

📅 Original date posted:2011-12-14
🗒️ Summary of this message: A suggestion was made to simplify the use of a URL instead of hardcoding specific elements, but the example given was not a valid URI.
📝 Original message:On Wednesday, December 14, 2011 2:22:12 PM D.H. wrote:
> > Then forget the hardcoding of "https" the hardcoding of "bitcoin-alias"
> > and> "?handle=" and the original email-looking "genjix at foo.org". Just
> > use the URL.> Then the author of the service can use whatever they want.
>
> I like this a lot. It's very simple to understand and would be very
> easy to implement and set up.
>
> "Sure, send it to david.bitcoin.se".
That's not a valid URI.

2023-06-07 02:46:06 UTC

- reply

📅 Original date posted:2011-12-13
🗒️ Summary of this message: Amir Taaki sent 1 BTC to brmlab, but Joe Address Squatter received it instead, according to a revised history.
📝 Original message:On Monday, December 12, 2011 9:37:06 PM Amir Taaki wrote:
> In our revised history, I simply send 1 BTC to brmlab
And then Joe Address Squatter gets 1 BTC. BOOM.

2023-06-07 02:45:07 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Discussion on using binary data in Bitcoin and the limitations of JSON-RPC for developer accessibility. MIME suggested as an alternative.
📝 Original message:On Monday, December 19, 2011 1:52:54 PM Jordan Mack wrote:
> I believe I'm missing something here. I was under the interpretation
> that alias resolution was going the KISS route, of basically a single
> HTTP request and response. How do you see binary data fitting into this?
Bitcoin is a binary system. Not all payment outputs are necessarily
serializable into addresses, and assuming they are would be broken-by-design.
In other words, why send the user's *software* "pay to address foo" just to
have it turn that into a script (of limited subset), when you can send the
script itself and avoid all the possible problems? Doing this right also means
that if the user's client doesn't support version 255 addresses, it still
works fine.
> I'm not going to pretend that I know all the details of the difficulties
> that were encountered with JSON-RPC. But in the argument of developer
> accessibility, it still serves a purpose. If JSON-RPC support is
> removed, you will immediately lose a large pool of high level language
> developers.
JSON isn't problem-free at high-level either. To summarize one of the issues,
almost every implementation of JSON treats Numbers differently based on
whether they have a '.' in them or not.
MIME has been around much longer, and should have sufficient support in every
language by now. For some reason, Python calls the module 'email'.

2023-06-07 02:45:01 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: A developer suggests using HTTPS and requiring TLS/SSL for Bitcoin, while discussing the use of JSON-RPC and binary data in Bitcoin transactions.
📝 Original message:On Monday, December 19, 2011 12:04:34 PM Jordan Mack wrote:
> I still think HTTPS should be used, at the minimum. Using HTTPS is
> standard to every website out there that deals with financials, even if
> it is not a perfect system. Why should Bitcoin adopt a more lax policy
> than everyone else?
Sure, I meant HTTP as the underlying protocol.
TLS/SSL should of course be required in some form.
> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here.
JSON-RPC won't go on forever. In any case, bitcoind's use of JSON-RPC is
exactly why I (and many other developers) have come to the realization how
poorly supported JSON really is. Most of the common languages do have a
library, but almost all of them have one issue or another (particularly around
the very undefined Number type).
XML shares the same binary-data problem as JSON, too.
As slush mentioned, no additional serialization is necessary anyway.
> Binary data can be base64 encoded, although I'm not sure why you would need
> to send back binary in an alias response.
Because computers work with binary. I don't think anyone wants to implement a
fully functional script assembler just to send funds.
> What exactly do you mean by "custom output script"?
This suggests you need to learn more about how Bitcoin works ;)
https://en.bitcoin.it/wiki/Script

2023-06-07 02:44:36 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Stick to simple standards like HTTP instead of using JSON which has poor language support and cannot represent binary data effectively.
📝 Original message:On Monday, December 19, 2011 2:56:09 AM Jorge Timón wrote:
> For the "answer format" JSON seems ok,
I'd prefer we stick to simple standards.
HTTP alone should really be fine to build on...
JSON in particular has very poor language support, and cannot reasonably
represent binary data (such as a custom output script). The HTTP
specification, however, allows binary data in multipart content just fine.

2023-06-07 02:44:30 UTC

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Proposal to limit trusted CA certificates for Bitcoin client to those with good identity verification practices, but this may limit accessibility.
📝 Original message:On Monday, December 19, 2011 6:44:59 AM Andy Parkins wrote:
> Perhaps we should be more strict about which CA certificates are trusted by
> the bitcoin client: say restrict it to those who have demonstrably good
> practices for verifying identity; rather than the ridiculous amount of
> trust that comes pre-installed for me in my browser.
Accepted CAs is/should be a property of your *operating system*, not any
particular software. Anyhow, restricting this further just makes it even more
unusable. Already there is only 1 or 2 CAs that will provide a gratis
certificate for personal/small users. If you only allow high-class CAs, I
imagine that will restrict "no key in the URI" aliases to those who will fork
over a lot of money.

2023-06-07 02:44:10 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: A proposal suggests hiding the bitcoin address from users and storing it with the URI in an address book, similar to SSH key warnings.
📝 Original message:On Sunday, December 18, 2011 8:14:20 PM Pieter Wuille wrote:
> Furthermore, the embedded bitcoin address could be hidden from the user:
> retrieved when first connecting, and stored together with the URI in
> an address book. Like ssh, it could warn the user if the key changes
> (which wil be ignored by most users anyway, but what do you do about
> that?)
Like SSH, don't make it easy to ignore.
eg, to ignore it, you need to manually go in and remove it from the URI.

2023-06-07 02:44:04 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: Extended URIs allow servers to negotiate payment details, making aliases practical for organizations that trust a CA with their funds.
📝 Original message:On Sunday, December 18, 2011 6:58:37 PM slush wrote:
> Maybe I'm retarded, but where's the point in providing alliases containing
> yet another hash in URL?
The point of the extended URI is to allow the server to negotiate payment
details (payment/order information, fees, new privacy address, etc) rather
than merely sending a simple payment to a single fixed address.
I am not convinced *aliases* are practical, without CA trust. An organization
that wants to trust a CA with all their funds can leave off the address
portion, to provide more human-friendly URIs.

2023-06-07 02:43:58 UTC

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: Discussion on integrating Namecoin to map server IPs using simple URI proposal. Authentication of host and negotiation of payment protocol also discussed.
📝 Original message:On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> If we chose the simple URI proposal namecoin can still be integrated
> to map the IP of the server by those who want to.
> Does it removes the necessity of the certificates?
> If so, we should let people decide between HTTP, HTTPS, namecoin or
> whatever they trust.
How are you going to authenticate the host? Certificates from CAs are how
HTTPS does it. HTTP is vulnerable. If the URI contains an address (eg,
bitcoin://remotehost/base58key), the remote host could sign its (self-signed)
SSL key with the ECDSA key to prove authenticity. DNSSEC/namecoin presumably
has some way to do this as well.
> Shouldn't we be also discussing the valid format of the answered
> message? I mean fields like "amount", "concept" and such.
At some point, a proper protocol to negotiate payment is needed for anything
like this.

2023-06-07 02:43:06 UTC

- reply

📅 Original date posted:2011-12-12
🗒️ Summary of this message: FirstBits may attract a rush to acquire desirable addresses, HTTPS is not foolproof, and addresses are likely unavoidable.
📝 Original message:FirstBits looks nice at glance, but is bound to create a gold-rush to grab
every nice-looking FirstBits address.
HTTPS is only as secure as the (centralized) CAs, thus not really any better
than TXT records.
I don't think an address of some form is avoidable.

2023-06-07 02:37:33 UTC

- reply

📅 Original date posted:2011-11-05
🗒️ Summary of this message: Christian Decker opposes using user-agent strings as it may lead to developers making communication choices based on client type, but some find it valuable for bug detection.
📝 Original message:On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote:
> Sorry for shooting this approach down, but I'm against it. User-agent
> strings are an extremely bad idea as it would lead developers to start
> making communication choices depending on the client type.
This can be necessary in some cases. What happens when some popular client is
found with a subtle bug, and cannot otherwise be differentiated from other
similar-functionality clients? I have found User-Agent very valuable when
dealing with the wide variety of miner bugs when I have enabled new
functionality/behaviour on Eligius.

2023-06-07 02:37:17 UTC

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: Amir Taaki suggests calling the original client reference protocol "Satoshi" as homage, but notes that the wxWidgets client was retired by version 0.5.
📝 Original message:On Wednesday, November 02, 2011 6:55:27 PM Amir Taaki wrote:
> I think calling it Satoshi is apt homage to the person who made the
> original client reference protocol.
My point is that the "Satoshi client" was the wxWidgets client, which was
retired by 0.5.

2023-06-07 02:37:11 UTC

- reply

📅 Original date posted:2011-11-02
🗒️ Summary of this message: "Satoshi 0.5" refers to the latest version of the Bitcoin software, which includes the bitcoind server and Bitcoin-Qt GUI client. The previous wx GUI client is no longer available.
📝 Original message:On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote:
> "Satoshi 0.5"
What is "Satoshi 0.5" anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt;
the wx GUI client is gone, which is more or less what "Satoshi" referred to in
the past...

2023-06-07 02:31:07 UTC

- reply

📅 Original date posted:2011-10-03
🗒️ Summary of this message: Upgraded nodes must not forward or mine invalid transactions, apply old behavior before a certain height, and begin applying new rules after a certain point.
📝 Original message:On Monday, October 03, 2011 12:53:51 AM Gregory Maxwell wrote:
> Upgraded nodes get the following rules:
> (0) Never forward or mine a txn which would be invalid under the new rule.
> (1) Apply old behavior before height X unconditionally.
> (X set far enough in the future to get reasonable deployment by
> large miners)
> (2) Begin applying the new rule only after the first point in the chain
> after X when none of the last Y blocks have contained an invalid
> transaction under the new rules.
Perhaps as a safeguard:
(3) Before applying the new rule, require 50% of the last Y blocks contain a
coinbase with a "I am upgraded" code
(4) Until the new rule is active, include an "I am upgraded" code in every
block; after it's active, this can be turned off
> After the software has been released members of the bitcoin community then
> begin _intentionally_ transmitting transactions which are invalid under
> the new rules. (What would have been an attack under simplest deployment
> plan)
Why would legitimate community members ever intentionally transmit an invalid
transaction? ;)

2023-06-07 02:26:30 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Suspicious transaction patterns should be investigated, but caution should be exercised when disconnecting nodes as they may only be relaying transactions.
📝 Original message:On Thursday, September 15, 2011 12:04:37 PM kjj wrote:
> On the other hand, the vast, vast majority of all transactions follow a
> particular pattern. If someone gives you one that doesn't match the
> standard pattern, you might be a little suspicious, but it is no big
> deal. But, if they emit dozens or hundreds, it is hardly unreasonable
> to disconnect them until you figure out what's going on.
That would make sense if you knew the node was originating them, MAYBE--
but not given the fact that they may merely be relaying transactions.

2023-06-07 02:26:20 UTC

- reply

📅 Original date posted:2011-09-15
🗒️ Summary of this message: Penalizing "non-standard" transactions or those with insufficient fees is not fair. It should be configurable, not punished, as it could ban legitimate nodes.
📝 Original message:On Thursday, September 15, 2011 8:56:24 AM kjj wrote:
> Luke-Jr wrote:
> > On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
> >> I'm looking for review of this pull request:
> >> https://github.com/bitcoin/bitcoin/pull/517
> >
> > "Non-standard" transactions, or those with "insufficient" fees should not
> > be penalised. These are properly relay/miner policy decisions, not
> > protocol violations, and should be made more easily configurable, not
> > punished for configuration.
>
> A few non-standard transactions are probably legitimate. A whole bunch
> of them are probably not. I would think that assigning a point or two
> of badness to a peer sending one is pretty reasonable, with the
> understanding that we would need to adjust that as the network evolves.
No. There is no such thing as "non-standard transactions" really; it is simply
"transactions outside of the bounds that I as a user/miner will relay/accept".
It is perfectly legitimate for other users/miners to relay/accept transactions
more liberally. By penalising for transactions falling outside of your
*personal policies*, you would end up banning many legitimate nodes.

2023-06-07 02:26:11 UTC

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: A request for review of a pull request regarding "non-standard" transactions and insufficient fees not being penalized but rather made configurable.
📝 Original message:On Wednesday, September 14, 2011 9:57:00 PM Gavin Andresen wrote:
> I'm looking for review of this pull request:
> https://github.com/bitcoin/bitcoin/pull/517
"Non-standard" transactions, or those with "insufficient" fees should not be
penalised. These are properly relay/miner policy decisions, not protocol
violations, and should be made more easily configurable, not punished for
configuration.

2023-06-07 02:25:30 UTC

- reply

📅 Original date posted:2011-09-14
🗒️ Summary of this message: Changing block timestamp rules could cause a chain split, but enforcing rules to discourage blocks with stale timestamps could prevent cartel manipulation.
📝 Original message:On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:
> The block timestamp rules currently give HOURS of wiggle-room for
> timestamps. We can't change those rules without risking a chain split.
And those hours of wiggle-room are not enough to cause a problem.
The problem only comes in (AFAIK) when the existing rules are *not* enforced.
> Assuming a majority of pools/miners adopt the "discourage blocks with
> stale timestamps" rule, that should squash any incentive for cartels
> to try to start playing with difficulty-- you would have to have 50+%
> power to start, or you risk producing mostly orphan blocks.
As this is against pools/miners' interests, and doesn't seem to solve any real
problems, I'm going to discourage its adoption if it ever gets done.

2023-06-07 02:25:03 UTC

- reply

📅 Original date posted:2011-09-13
🗒️ Summary of this message: Gavin Andresen proposes standard multi-signature transactions for better wallet backup and security, and suggests using deterministic keychains and signmessage for improved security.
📝 Original message:On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote:
> 3) I'd really like to come to consensus on one or more
> 'multi-signature' standard transactions to enable much better wallet
> backup and security.
More important in this area, IMO, is support for deterministic keychains in
wallets. Type 2, according to gmaxwell's original spec, seems pretty ideal,
and significantly improves security for many use cases. Since it allows a
wallet to contain a public keychain without the matching private keychain,
webservers, POS, and other services can be provisioned only with the keychain
required to generate/access infinite public keys, and without the private
keyroot needed to spend them.
The ideal scenario in this regard, as I see it, is this:
- Webserver wallets are provisioned with multiple public keychains (one per
webserver), and configured to use a specific one for getnewaddress/etc. By
provisioning them with *all* the public keychains, their listtransactions/etc
can see the transactions sent to other webservers, necessary to show
confirmations to the end user and such.
- Business keeps a locked-down *offline* wallet with the private keychains for
all the forementioned public keychains. Only this wallet has the information
required to spend the income. The wallet is encrypted, and can only be
accessed by staff with the proper position/authority to authorize expenses.
- A third wallet is used by staff to prepare expense transactions. It keeps
track of locking coins it knows are in the process of being spent, and any
staff member can create new ones. Once created, they must submit the
transaction to a staff member with the proper authority to bring it to the
offline transaction-signing wallet (on a USB key), where it is signed, and
returned to this third wallet.
Another feature that needs some attention is signmessage. It can be used to
send a transaction id/summary to a specified email address signed by the
sending key of the same transaction (these can be added to the send-money
GUI). This would allow merchants to publish a single payment address and still
be able to verify which customers sent payment.

2023-06-07 02:18:00 UTC

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: A discussion on Bitcoin's block size limit and difficulty adjustment, with suggestions for dynamic adaptation and increased precision, but concerns about potential issues.
📝 Original message:On Wednesday, August 24, 2011 12:46:42 PM Gregory Maxwell wrote:
> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke at dashjr.org> wrote:
> > - Replace hard limits (like 1 MB maximum block size) with something that
> > can dynamically adapt with the times. Maybe based on difficulty so it
> > can't be gamed?
>
> Too early for that.
Dynamically adapting would be by design never too early/late. Changing from a
fixed 1 MB will fork the block chain, which should be a minimized event.
> > - Adjust difficulty every block, without limits, based on a N-block
> > sliding window. I think this would solve the issue when the hashrate
> > drops overnight, but maybe also add a block time limit, or perhaps
> > include the "current block" in the difficulty calculation?
>
> The quantized scheme limits the amount of difficulty skew miners can
> create by lying about timestamps to about a half a percent. A rolling
> window with the same time constant would allow much more skew.
Depends on the implementation, I'd think.
> > Replacing the "Satoshi" 64-bit integers with
> > "Satoshi" variable-size fractions (ie, infinite numerator + denominator)
>
> Increasing precision I would agree with but, sadly, causing people to
> need more than 64 bit would create a lot of bugs.
>
> infinite numerator + denominator is absolutely completely and totally
> batshit insane. For one, it has weird consequences that the same value
> can have redundant encodings.
So? You can already have redundant transactions simply by changing the order
of inputs/outputs. A good client would minimize the transaction size by
reducing them, of course.
> Most importantly, it suffers factor inflation: If you spend inputs
> 1/977 1/983 1/991 1/997 the smallest denominator you can use for the
> output 948892238557.
I already tried to address this in my original mail. If I had those 4 coins, I
would use a denominator of 987 and discard the difference as fees.

2023-06-07 02:17:54 UTC

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen suggests implementing or enabling opcodes to enable smaller bitcoin addresses and scheduling a blockchain split to fix various issues.
📝 Original message:On Wednesday, August 24, 2011 11:12:10 AM Gavin Andresen wrote:
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
If a block chain split is to occur, it makes sense to try to fix as many
problems as possible:
- Replace hard limits (like 1 MB maximum block size) with something that can
dynamically adapt with the times. Maybe based on difficulty so it can't be
gamed?
- Adjust difficulty every block, without limits, based on a N-block sliding
window. I think this would solve the issue when the hashrate drops
overnight, but maybe also add a block time limit, or perhaps include the
"current block" in the difficulty calculation?
- 21 million really isn't enough if Bitcoin ever takes off, even with
100,000,000 units per BTC. Replacing the "Satoshi" 64-bit integers with
"Satoshi" variable-size fractions (ie, infinite numerator + denominator)
would create infinite possibilities of future divison, allowing people to
not only do nBTC and pBTC, but also exact 1/3 of any quantity. Transaction
size would go up based on the number of primes involved in an amount, which
would encourage discarding annoying primes in transaction fees.
- Standardize everything on network (big) endian.
I'm sure others can think of other chain-splitting fixes that wouldn't be too
much work to fix.

2023-06-07 02:11:24 UTC

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: Bitcoin security vulnerabilities discussed at BH 2011 by Dan Kaminsky, but claims of a tool called "blitcoin" unmasking transactions are unfounded as transparency is by design.
📝 Original message:On Thursday, August 04, 2011 6:56:42 AM John Smith wrote:
> L.S.
>
> Some bitcoin "security vulnerabilities" have been discussed by Dan Kaminsky
> at BH 2011, there is one article about this dated yesterday:
>
> http://searchsecurity.techtarget.com/news/2240039221/Black-Hat-2011-Dan-Kam
> insky-reveals-network-security-research-topics
>
> The article is very unspecific though. They talk about a tool called
> "blitcoin" that "unmasks" both sides of a bitcoin transaction. A google
> search also turned up nothing, except some misspellings.
Well, that certainly doesn't sound like a security vulnerability at all.
It's by design that everyone knows about every transaction.

2023-06-07 02:08:23 UTC

- reply

📅 Original date posted:2011-07-27
🗒️ Summary of this message: A suggestion to add a way for anyone to add to the bounty attached to a bug on the bug tracker and a listing page for bugs with their bounties was made. Concerns were raised about GitHub's steep demand for potentially unlimited money.
📝 Original message:On Wednesday, July 27, 2011 10:20:07 AM John Smith wrote:
> On Wed, Jul 27, 2011 at 11:14 AM, Joel Joonatan Kaartinen
> <joel.kaartinen at gmail.com> wrote:
> > Perhaps even add a way for anyone add to the bounty attached to a bug on
> > the bug tracker? Also, a listing page for bugs with their bounties might
> > be nice too.
>
> Good idea. I'm not sure if the github bug tracker supports extension
> attributes, but it'd be a great place to add it. Also, people can let know
> that they're already working on a feature using a comment, to prevent
> double work.
I'm not sure a few small bounties would justify agreeing to GitHub's steep
demand for potentially unlimited money in their terms of service...

2023-06-07 02:05:40 UTC

- reply

📅 Original date posted:2011-07-14
🗒️ Summary of this message: Securely delete old wallet.dat by overwriting with random data. Mark keys from unencrypted files as potentially compromised and avoid using them for new addresses.
📝 Original message:Just wanted to get these suggestions out here:
1. Write over the old, unencrypted wallet.dat a couple of times with pseudo-
random data in an attempt to secure-delete it.
2. Mark all the keys imported from an unencrypted file (wallet or otherwise)
as "potentially compromised" and never use them for new addresses
(basically, don't use the old keypool for getnewaddress, change, and such).

2023-06-07 02:01:30 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: A discussion about the use of autotools versus cmake as a build system, with concerns about cmake not following the standard build procedure.
📝 Original message:On Saturday, July 02, 2011 12:50:14 PM John Smith wrote:
> On Sat, Jul 2, 2011 at 2:50 PM, Luke-Jr <luke at dashjr.org> wrote:
> > On Saturday, July 02, 2011 3:29:04 AM John Smith wrote:
> > > Why again did we choose for autotools as future build system instead of
> > > cmake?
> >
> > I don't really care much either way, but cmake doesn't follow the
> > standard build procedure (./configure && make && make install), though I
> > imagine ./configure could be emulated with some script.
>
> It would change the sequence to
>
> cmake . && make && make install
>
> So a shell script named 'configure' that starts 'cmake .' is the most easy
> case :-) Probably it'd also need to pass through some command line args,
> for example --prefix.
And --datadir --mandir --randomobscurecrap CXXFLAGS=-O9, etc
Don't forget --help listing all the useful options... that's the big thing I
miss with CMake-stuff.

2023-06-07 02:01:24 UTC

- reply

📅 Original date posted:2011-07-02
🗒️ Summary of this message: John Smith questions the decision to use autotools instead of cmake as the future build system, citing cmake's deviation from the standard build procedure.
📝 Original message:On Saturday, July 02, 2011 3:29:04 AM John Smith wrote:
> Why again did we choose for autotools as future build system instead of
> cmake?
I don't really care much either way, but cmake doesn't follow the standard
build procedure (./configure && make && make install), though I imagine
./configure could be emulated with some script.

2023-06-07 01:21:42 UTC

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Pieter Wuille suggests merging a new GUI, stating that the necessary cleanup of RPC/GUI code will require changes in three places instead of two.
📝 Original message:On Friday, June 17, 2011 6:31:25 AM Pieter Wuille wrote:
> The only disadvantage of another GUI is that the (necessary) cleanup of
> RPC/GUI code will now need makes changes in 3 places instead of 2, but as
> I understand it, there are much more people willing to work on Qt code
> than on wx code?
I'm not sure the Wallet protocol implementation needs to touch the GUI code at
all, except when porting the GUI to use it. Therefore, if the code is already
written, I don't see any harm in merging it.