Luke-Jr [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-16 to 2014-04-29
💬 Posted a total of 314 messages
📚 Participated in the following categories: Bitcoin-development, RFC, PULL, 0O, l|!, PATCH, PULLs, RFCs, BIP 15, -test, BIP proposal
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs

Profile Code

nprofile1qqsx4349rx64fk8lwf4rq83a4mqtfz05gdunw787enrw57jndae4fugprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueq9d2xfc

Publishing to

relay.noswhere.com

relay.nostr.band

Author Public Key

npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs

Show more details

Last Notes

2023-06-07 15:18:02

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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:55

- 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

- 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:13:58

- reply

📅 Original date posted:2014-02-24
📝 Original message:On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote:
> Regarding 80 bytes vs smaller: The objectives should be that if you are
> determined to put some extra data in the blockchain, OP_RETURN should be
> the superior alternative. if a user can include more data with less fees
> using a multisig TX, then this will happen.
>
> eventually dust-limit rules will not be the deciding factor here, since
> i suspect block propagation times will have a stronger effect on
> effective fees. therefore a slightly larger payload than the biggest
> multisig TX is the right answer. - that would be >= 64x3 bytes = 192 bytes.
> (this is my understanding of how large a 3-of-3 multisig tx can be, plus
> 1.5 bits encoded in the "n" parameter)
Perhaps I ought to redo my data carrier configuration option as a max size?
Luke

2023-06-07 15:13:31

- reply

📅 Original date posted:2014-02-10
📝 Original message:On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote:
> The proposed document is here: https://gist.github.com/sipa/8907691
Rule 3 & 4 are already enforced.
AFAIK nVersion==3 transactions are not currently considered non-standard?
Luke

2023-06-07 15:13:23

- 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:16

- reply

📅 Original date posted:2014-01-17
📝 Original message:On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote:
> <vendor hat: on> BitPay sure would like to see CPFP in upstream.
>
> I think the main hurdle to merging was that various people disagreed
> on various edge case handling and implementation details, but no
> fundamental objections.
Heck, even I disagree with implementation details, but it's still better than
nothing. We can always merge major reorganisations/reimplementations later
when they're written: merging this one doesn't mean we're stuck with it
forever...
Luke

2023-06-07 15:11:14

- reply

📅 Original date posted:2014-01-01
📝 Original message:On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote:
> On Tue, Dec 31, 2013 at 01:14:05AM +0000, Luke-Jr wrote:
> > On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
> > > that you are using merge-mining is a red-flag because without majority,
> > > or at least near-majority, hashing power an attacker can 51% attack
> > > your altcoin at negligible cost by re-using existing hashing power.
> >
> > I strongly disagree on this isolated point. Using the same logic, Bitcoin
> > is vulnerable to an attacker at negligible cost by re-using existing
> > hashing power from mining Namecoin. Any non-scam altcoin is pretty safe
> > using merged mining, since any would-be attacker is going to have it in
> > their interests to invest in the altcoin instead of attacking it. It's
> > only the scam ones that want to pump & dump with no improvements, that
> > are really at risk here.
> >
> > The rational decision for a non-scam altcoin, is to take advantage of
> > merged mining to get as much security as possible. There are also some
> > possible tricks to get the full security of the bitcoin miners even when
> > not all participate in your altcoin (but this area probably needs some
> > studying to get right).
>
> You assume the value of a crypto-currency is equal to all miners, it's
> not.
>
> Suppose I create a merge-mined Zerocoin implementation with a 1:1
> BTC/ZTC exchange rate enforced by the software. You can't argue this is
> a scamcoin; no-one is getting rich. There's a 1:1 exchange rate so the
> only thing you can do with the coin is get some privacy. But inevitably
> some miners won't agree that enabling better privacy is a good thing, or
> their local governments won't. Either way, they can attack the Zerocoin
> merge-mined chain with a marginal cost of nearly zero.
Not necessarily. If Zerocoin was tied directly to Bitcoin proof-of-work, the
worst they could do is not-participate by mining empty blocks.
> OTOH if the Zerocoin scheme was implemented by embedding ZTC
> transactions within standard Bitcoin transactions - even without any
> attempt at hiding them - the attackers would need a 50% majority of
> hashing power to succeed. Of course potentially slow confirmations is a
> trade-off, but that's likely a perfectly OK trade-off in this case.
Potentially slow confirmation is also the only shortcoming of using Bitcoin's
proof-of-work directly.
Luke

2023-06-07 15:10:26

- 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:09:36

- 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

- 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

- 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

- 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

- 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:09

- 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

- 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:06:41

- reply

📅 Original date posted:2013-09-07
📝 Original message:On Saturday, September 07, 2013 11:21:31 PM rob.golding at astutium.com wrote:
> > bitcoin protocol needs an archival system so the blockchain doesn't
> > become too big to download
>
> Some people may want it all ...
>
> Balance at Point-In-Time summaries (say up to the penultimate
> difficulty adjustment) would be one simple way.
> And make new-adopters get up and running in minutes not days, which can
> only be a good thing.
There's no reason to require the full blockchain download before being up and
running. Bitcoin-Qt 0.9 will (probably) have Pieter's work in this area to be
usable very quickly, and download/verify the history in the background
(there's no way to be completely trust-free without this).
> If going that route, then solutions to the 'consolidate addresses/wallets'
> question and formal 'discard' of addresses could get addressed.
Not sure what you mean here. Addresses and wallets are two completely
different things. Addresses are single-use destinations that point to a wallet
(which is itself private and unknown to the network).
Luke

2023-06-07 15:05:17

- reply

📅 Original date posted:2013-07-29
📝 Original message:On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
> What are your thoughts on creating a whitelist for specific opcodes that
> would apply to scripts serialized using P2SH, retaining the existing
> standard whitelist for scriptPubKeys? (I would still recommend dropping
> pay-to-pubkey and pay-to-multisig due to their potential for dumping data
> in the UTXO set)
This would be reasonable for miners, but for interoperability between wallets,
some specific standard forms would still be necessary without a much smarter
solver (which would then expand the code required to implement a wallet, which
is unfortunate if not entirely necessary).

2023-06-07 15:04:18

- reply

📅 Original date posted:2013-07-14
📝 Original message:On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
> On Sun, Jul 14, 2013 at 08:16:41PM +0000, Luke-Jr wrote:
> > P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
> > well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
> > new economic idea as well ;)
>
> Your ideas about making an alt-coin have anything to do with hashing
> power might be a lot more convincing if you hadn't 51% attacks alt-coins
> in the past.
Slander like this does not belong on the dev ML.

2023-06-07 15:03:57

- 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

- 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:04

- reply

📅 Original date posted:2013-05-26
📝 Original message:On Thursday, May 16, 2013 10:02:05 AM bitcoingrant at gmx.com wrote:
> One of the main goals will be to separate the wallet from the node, as we
> have already done with mining.
How is this different from what Electrum has already done?
Luke

2023-06-07 11:41:03

- reply

📅 Original date posted:2013-03-23
📝 Original message:On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
> Introducing super-nodes with thousands of connected peers can greatly help
> here.
UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
Luke

2023-06-07 11:39:01

- 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

- 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:37:37

- reply

📅 Original date posted:2013-03-12
📝 Original message:On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
> I'm sure it won't be long before Slashdot and a variety of sources start
> reporting on this event. Bitcoin has been in the media a lot lately, so
> this story is likely to get some attention. The blowback of this event
> is mostly psychological, so I think it would be exceptionally wise to
> start preparing PR comments that can be posted on articles immediately
> after they go public. This event is likely draw much more negative
> attention than it deserves, and getting some positive&informed comments
> posted up front will potentially make a difference in the way the story
> is received.
>
> Undoubtedly, many articles (and especially commenters) will shape this
> into "the end of Bitcoin". I would describe it as "there was a short
> and mostly-harmless lapse in the ability of the network to reach a
> consensus, causing transactions to get delayed by a few hours." It
> *really* needs to be emphasized that coins are safe, and nothing anyone
> has/could do will change that. And that it would've been extremely
> difficult to exploit for gain. Transactions got delayed while a bug was
> fixed. End of story.
I think we should be careful not to downplay the reality either.
For a number of hours, transactions could have received up to N confirmations
and then still been reversed. While we could contact the bigger payment
processors, I saw people still trying to buy/sell on OTC, whom could have been
scammed even by taking standard precautions.
Luke

2023-06-07 11:31:45

- 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

- 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

- 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:39:37

- 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

- 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:36:15

- reply

📅 Original date posted:2012-10-14
📝 Original message:On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote:
> Given that sourceforge has shown to restrict access to a number of
> countries at the request of the USA
This needs some clarification. If the USA has "requested" it, then presumably
there's some legality involved, and our US developers shouldn't be made liable
for it. The specific reason SourceForge has restricted access should be made
known so non-US developers (or gitian builders) can evaluate their own laws
and hopefully at least one will be in a jurisdiction that allows it.
But GitHub is also US-located, so hosting it there may be a problem too.
Luke

2023-06-07 10:27:41

- reply

📅 Original date posted:2012-08-02
📝 Original message:On Thursday, August 02, 2012 4:43:25 PM Jeff Garzik wrote:
> Opening the floor... What do we collectively want to happen, before
> 0.7 release? What is the todo list for 0.7?
Based on pull-capable dev comments, I've personally noted these branches as
accepted for 0.7:
> 7) HOPEFULLY: Addnode optimization and addnode access via RPC
> BlueMatt https://github.com/bitcoin/bitcoin/pull/1549
>
> 8) MAYBE: Transition to requiring block height in block coinbases
> gavinandresen https://github.com/bitcoin/bitcoin/pull/1526
>
> 10) I THINK WE WANT THIS? Make IPv6 support optional again (defaults
> to enabled)
> luke-jr https://github.com/bitcoin/bitcoin/pull/1431
>
> 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
> luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor transaction/accounting time
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1393
I also personally feel these are appropriate and ready for 0.7:
> 4) Add 'mempool' P2P command, and extend 'getdata' behavior
> jgarzik https://github.com/bitcoin/bitcoin/pull/1641
>
> 6) JSON-RPC method: prioritisetransaction <txid> <priority delta>
> luke-jr https://github.com/bitcoin/bitcoin/pull/1583
>
> 9) RPC: add facility to enable RPCs to run outside cs_main, wallet locks
> jgarzik https://github.com/bitcoin/bitcoin/pull/1493
+
+ m) Treat generation (mined) transactions less different from receive
+ transactions
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1409
Also these, but they need testing:
> 1) CreateNewBlock: Child-pays-for-parent / Add transaction fee later
> luke-jr https://github.com/bitcoin/bitcoin/pull/1647
>
> 5) PROBABLY NOT, BUT MAYBE: Relay blocks as a "preview" before
> checking the transactions in them
> luke-jr https://github.com/bitcoin/bitcoin/pull/1586
+
+ m) Bitcoin-Qt (Windows only): enable DEP for bitcoin-qt.exe
+ diapolo https://github.com/bitcoin/bitcoin/pull/1614
I also feel it is very important that Wumpus/laanwj decide on a name for his
client (formerly known as Bitcoin-Qt) and add it to the software instead of
simply claiming it is "Bitcoin" as it has for a week or so now - that change
is anticompetitive and will confuse new users into thinking Bitcoin is the
software too easily.
Luke

2023-06-07 10:24:17

- reply

📅 Original date posted:2012-07-22
📝 Original message:On Monday, July 23, 2012 12:41:15 AM Gavin Andresen wrote:
> > The current block height in coinbase addition currently proposes to use
> > block version 2. However, the protocol change is in fact to the coinbase
> > transaction, not the block itself (which really doesn't have any
> > extensibility without a hardfork anyway). Perhaps we should consider
> > bumping the coinbase transaction version number to 2 for this instead?
>
> I'd thought about bumping the coinbase transaction version, but the
> problem is if we want a smooth rollout then, during the rollout, every
> time a new block comes in the percentage of the last 1,000 blocks that
> support the new version has to be computed.
>
> If that means looking in the coinbase transaction, then either the
> last 1,000 coinbases have to be stored in memory or they have to be
> fetched from disk. Which isn't a huge deal, unless we start
> aggressively pruning spent transactions, and that coinbase 900 blocks
> back got spent and pruned.
Any reason CBlockIndex couldn't cache the coinbase version?
> On Sun, Jul 22, 2012 at 4:52 PM, Luke-Jr <luke at dashjr.org> wrote:
> > It just occurred to me that the block version number could easily be used
> > as a cheap "extra nonce" right now. Considering that we will probably
> > see lots of ASIC miners running at 1 TH/s per rig before the end of
> > 2012, it might be desirable to save the block version for this purpose.
>
> Hmm... I think it'd be ok to give 3 of the 4 block version bytes as a
> simple extranonce, so version=0x00000001 is what we have now, version
> 2 blocks are any with 0x02 in the low byte, 0x03 is version 3, etc. I
> don't think we'll go through 253 block versions before we're all dead.
>
> That'd be 7 bytes of nonce in the block header, which is
> 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
>
> So: the changes for version 2 blocks would be "has height in the
> coinbase, and has a 1-byte version number with a 3-byte extranonce."
That sounds workable.
> > Also, Jeff noticed that block 190192 has version==2 without a valid block
> > height in the coinbase. I suspect this may be the result of combining the
> > current blockheight-in-coinbase pullreq with P2Pool. This means that if
> > we go forward with the version==2 marker, we will forever need to make
> > an exception for that block.
>
> No, the rules are "enforce the rules when the chain has a
> super-majority." Since block 190192 is in a part of the chain with
> zero other version==2 blocks, the height-in-the-coinbase rule will not
> be enforced.
I was thinking more of the end-game of changing the rule to simply "if
version==2, require the height in coinbase" after the point of no return is
met without any infringement.

2023-06-07 10:24:10

- reply

📅 Original date posted:2012-07-22
📝 Original message:It just occurred to me that the block version number could easily be used as a
cheap "extra nonce" right now. Considering that we will probably see lots of
ASIC miners running at 1 TH/s per rig before the end of 2012, it might be
desirable to save the block version for this purpose.
The current block height in coinbase addition currently proposes to use block
version 2. However, the protocol change is in fact to the coinbase
transaction, not the block itself (which really doesn't have any extensibility
without a hardfork anyway). Perhaps we should consider bumping the coinbase
transaction version number to 2 for this instead?
Also, Jeff noticed that block 190192 has version==2 without a valid block
height in the coinbase. I suspect this may be the result of combining the
current blockheight-in-coinbase pullreq with P2Pool. This means that if we go
forward with the version==2 marker, we will forever need to make an exception
for that block. Moving the version==2 to the coinbase transaction version also
means whoever makes that transaction (thus deciding whether to put the height
in it or not) also sets the version number - instead of the block version
coming from bitcoind and the coinbase transaction coming from P2Pool or other
software.
Thoughts?
Luke

2023-06-07 10:11:41

- reply

📅 Original date posted:2012-06-04
📝 Original message:On Monday, June 04, 2012 8:49:48 PM Mike Koss wrote:
> As I understand the attack, the attacker gets compensated for the shares
> they earn, but the pool will be denied any valid blocks found. The
> attacker DOES NOT have access to the Bitcoins earned in the unreported
> block (only the mining pool has access to the Coinbase address and
> transactions in the block).
With decentralized pools, the attacker does have access to the block, and can
potentially submit it to the Bitcoin network directly bypassing the pool if it
benefits them to do so.
> So it's a zero-net-cost attack for the attacker (but no chance of making a
> profit) to hurt the pool operator.
Because of the above, there is a possibility an attacker can make a profit.
> The only way to detect such an attack now is to look for "unlucky" miners;
> at the current difficulty, you can't detect this cheat until many millions
> of shares have been earned w/o a qualifying block. Since an attacker can
> also create many fake identities, they can avoid detection indefinitely by
> abandoning each account after a million earned shares.
There are other modes of detection, but nobody has bothered to implement them
since attackers can easily do a simple workaround in an arms race.
> I don't understand your proposal for fixing this. You would have to come
> up with a scheme where:
>
> - The miner can detect a qualifying hash to earn a share.
> - Not be able to tell if the hash is for a valid block.
With my proposal, miners can find shares, but won't know if it's a valid block
until the subsequent block is also found (that subsequent block might not end
up being a real block in the big picture).
> The way I would do this is to have a secret part (not shared with the
> miners) of a block that is part of the merkle hash, which is also used in a
> secondary hash. Difficulty is then divide into two parts: the first,
> solved by the miner (earning a "share" - e.g., 1 in 4 Billion hashes). And
> a second, solved by the pool (1 in Difficulty shares). A valid block would
> have to exhibit a valid Share Hash AND a valid Pool Hash in order to be
> accepted.
This only works for centralized pools, which are contrary to the health of the
Bitcoin network. Decentralized pools cannot have a secret.

2023-06-07 10:11:28

- reply

📅 Original date posted:2012-06-02
📝 Original message:Analysis, comments, constructive criticism, etc welcome for the following:
==Background==
At present, an attacker can harm a pool by intentionally NOT submitting shares
that are also valid blocks. All pools are vulnerable to this attack, whether
centralized or decentralized and regardless of reward system used. The
attack's effectiveness is proportional to ratio of the attacker's hashrate to
the rest of the pool.
There are obvious solutions that can be used to defeat this attack on
centralized pools. For example, including a secret in the coinbase transaction
that is accepted by the network as a partial preimage proof-of-work. All these
solutions require changes to Bitcoin's proof-of-work acceptance terms, and
since centralized pools can be harmful to the network's security, these rule
changes are not likely to gain enough acceptance among the greater Bitcoin
community.
==Proposed Solution==
Please comment on the viability of this new proof-of-work algorithm, which I
think should be viable for even decentralized pools:
Blocks are accepted at a lower difficulty N (choosable by the pool; eg, the
share difficulty) iff they are submitted with a candidate for the next block
and SHA256(SHA256(NewBlockHash + NextBlockCandidateHash)) meets difficulty M.
The relationship between M and N must be comparable to the normal network
difficulty; details on the specifics of this can be figured out later, ideally
by someone more qualified than me. M and N must be chosen prior to searching
for the block: it should be safe to steal some always-zero bytes from the
prevblock header for this.
This algorithm should guarantee that every share has an equal chance of being
a valid block at the time it is found, and that which ones are actually blocks
cannot be known until the subsequent block is found. Thus, attackers have no
way to identify which shares to withhold even while they have full knowledge
of the shares/blocks themselves.
==Backward Compatibility==
Obviously, this change creates a hard-fork in the blockchain. I propose that
if it solves the block withholding risk, the gain is sufficient that the
community may approve a hard-fork to take place 1-2 years from consensus.
Since mining continues to use a double-SHA256 on a fixed 80 byte header,
existing miners, FPGAs, etc should work unmodified. Poolservers will need to
adapt significantly.

2023-06-07 10:10:44

- reply

📅 Original date posted:2012-05-29
📝 Original message:On Tuesday, May 29, 2012 3:36:34 PM Peter Vessenes wrote:
> I suppose I mean that I don't understand how to reverse that into a URL
> when one is presented only with a block, or perhaps a coinbase in a
> transaction.
A new message can be added to the p2p relay network, similar to tx and alert
broadcasts, that allow miners to publish/update their policy URI signed by the
key in question. Counter-DDoS rules could decline to relay or store URIs for
keys that haven't been published in - or achieved statistical significance in
- the last N blocks.

2023-06-07 10:10:38

- reply

📅 Original date posted:2012-05-29
📝 Original message:On Tuesday, May 29, 2012 3:28:56 PM Peter Vessenes wrote:
> I don't understand what the 20 byte keyhash is. Can you elucidate?
20 byte keyhashes are a fundamental building block of the Bitcoin protocol.
ripemd160(sha256(ecdsaPubKey))

2023-06-07 10:10:19

- reply

📅 Original date posted:2012-05-29
📝 Original message:On Tuesday, May 29, 2012 8:52:49 AM Michael Grønager wrote:
> The format of the sla.php page should then be specified too - but it could
> be a json-rpc call returning a json object like (as result): {
> sla_version: "0.1",
> accept_no_fee_tx: false,
> min_fee: 50000,
> big_tx_fee: 10000, // extra fee pr kb
> }
> I guess miners could work out a more suitable set of fees...
Please not JSON, and not hard-coded logic. Bitcoin already has a secure
scripting system - perhaps we can decide on an initial stack format and run a
script retrieved from the URI?

2023-06-07 10:09:45

- 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

- 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

- 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:09:01

- reply

📅 Original date posted:2012-05-16
📝 Original message:On Wednesday, May 16, 2012 6:18:27 PM Jeff Garzik wrote:
> Instead of further overloading service bits in the version message, or
> altering the version message, let us instead make feature discovery an
> easy, flexible, extensible process.
>
> We can add new commands without impacting older nodes, so let's create
> a new command "get-features" (or pick your name) that returns a list
> of key/value pairs. The key is a string, the value type is determined
> by the key.
That assumes you already have a connection to the peer in question.
As I understand it, the service bits are propagated as part of the address,
so you can see at a glance which nodes you want to connect to for some
special service. Passing a huge list along might be unwieldy (though it
makes sense for protocol changes that don't add new services).

2023-06-07 10:03:14

- reply

📅 Original date posted:2012-04-11
📝 Original message:On Wednesday, April 11, 2012 11:32:18 AM Mike Hearn wrote:
> Jeff asked for a BIP for the pong message, so here it is:
>
> https://en.bitcoin.it/wiki/BIP_0031
I thought we were going with 60001 for the protocol version bump?

2023-06-07 10:02:38

- reply

📅 Original date posted:2012-04-03
📝 Original message:On Tuesday, April 03, 2012 2:46:17 PM Gavin Andresen wrote:
> We should avoid reinventing the wheel, if we can. I think we should
> extend existing standards whenever possible.
I wonder if it's possible to make sigs compatible with PGP/EC ?

2023-06-07 10:02:32

- reply

📅 Original date posted:2012-04-02
📝 Original message:On Monday, April 02, 2012 4:55:03 PM Alan Reiner wrote:
> Any thoughts? (I have no doubts that there are :) )
IMO, the sign-request URI should be an extension on the existing bitcoin: URI
scheme; this way, sigNeeded can be omitted to imply "sign with a sending
address".

2023-06-07 03:12:42

- reply

📅 Original date posted:2012-03-13
📝 Original message:On Tuesday, March 13, 2012 2:06:38 PM Mike Hearn wrote:
> https://github.com/bitcoin/bitcoin/pull/932 adds a "pong" message that
> echoes back a 64 bit nonce contained in the ping, if the protocol
> version is new enough.
>
> The goal of this is to make it easier for clients, especially mobile
> clients, to quickly check if a connection is stale, and also to see if
> a remote node is overloaded so we can avoid talking to it. A common
> case where this happens is if the remote node is itself downloading
> the block chain or doing something equally intensive.
>
> Any objections?
Not really an objection per se, but what's wrong with TCP keepalives?

2023-06-07 03:11:59

- reply

📅 Original date posted:2012-03-03
📝 Original message:On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote:
> > HTTP and JSON-RPC are a client-server model; there is no way for the
> > server to make calls to the client. It's not practical to expect clients
> > to run their own JSON-RPC server - many cannot listen on WAN ports at
> > all.
>
> You're doing that thing where either you say something before you've
> done adequate research, or you're being needlessly pedantic; I just
> copied and pasted this from section 2.1 of the JSON-RPC spec:
I wasn't aware anyone was considering JSON-RPC over anything other than HTTP.
I've updated the draft to include long polling, and remove some assumptions of
using HTTP for transport.

2023-06-07 03:11:05

- reply

📅 Original date posted:2012-03-02
📝 Original message:On Friday, March 02, 2012 1:51:41 PM Amir Taaki wrote:
> It is a implementation-specific non-bitcoin-protocol proposal. My
> understanding of BIPs is that they apply across bitcoin implementations
> and largely focus on the most generic use-cases (like the URIs) and the
> protocol. Things which affect all clients, and allow the system to
> function as a united whole.
This isn't implementation-specific. If you read it, you should notice it is
intentionally generic for multiple use-cases. Right now bitcoind supports
getmemorypool for a few use cases, but this proposed BIP enables it to be
utilized for many more. Specifically, Eligius and at least a few other pools
wish to move toward a more decentralized method of pooled mining (similar to
the proprietary p2pool protocol). Eligius already supports miners producing
their own work with getmemorypool using this draft, and our Eloipool server is
open source (AGPL-3) for others to adopt (I know of at least one other pool
planning to do so). Other pools not using Eloipool also have expressed
interest in this, so a standard is desirable.

2023-06-07 03:09:39

- 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 02:56:24

- 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

- 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:53:31

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: A user defends the use of random code in a script, despite concerns raised about its adequacy and potential risks.
📝 Original message:On Thursday, December 29, 2011 12:01:20 PM roconnor at theorem.ca wrote:
> This is not adequate: <data> OP_SHA256 OP_EVAL runs random code that is
> more than 5 bytes.
So what? Why shouldn't I be able to run random code? I could always put that
random code in the script verbatim, after all.

2023-06-07 02:52:14

- reply

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Bitcoin version 0.6 is being updated with 21 merged branches, including QR code generation and compressed pubkeys, with a release candidate due soon.
📝 Original message:On Tuesday, December 20, 2011 8:46:41 PM Luke-Jr wrote:
> On Tuesday, December 20, 2011 3:49:16 PM Gavin Andresen wrote:
> > I've been busy pulling patches into git HEAD for a Bitcoin version
> > 0.6, with the goal of having a Release Candidate 1 out in a couple of
> > weeks.
>
> I've rebuilt my 'next' and 'next-test' branches...
> git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git
And here's yet another update, this time with a total of 21 branches merged.
Anyone want to make binaries to get these branches some wider testing?
Accepted for 0.6:
* 81807c3 (pull 719) Coinbaser
* 6ea6db3 (pull 683) Context menu updates for TransactionView and...
* a6ef83e (pull 629) QR Code generation via libqrencode
* e0673bd (pull 582) Bitcoin-Qt signmessage GUI
Ready for acceptance?
* 4783528 (pull 454) Add -keepnode which attempts to -addnode and keep a...
* 5a11d0f (pull 570) Specify fees explicitly via JSON-RPC
* 2cddc71 (pull 649) Compressed pubkeys
* 73a8ca6 (pull 593) Full URL Support in bitcoin-qt
* 27a2460 (pull 721) 'getmininginfo' method
* e57ccf4 (pull 686) Testnet difficulty calculation changes, to take effect...
* 5b4a18d (pull 720) Use standard C99 (and Qt) types for 64-bit integers
Needs review:
* c7ee97d (pull 421) added option -forceresendtx
* cff2c28 (pull 714) Execute a command when best block changes...
* 3ca784f (pull 691) Temporarily disable "minimize to tray" in the startup...
* 59842f5 (pull 568) Multithreaded JSON-RPC with HTTP 1.1 Keep-Alive support
* d08e8fd (pull 565) FastGetWork optimization
* 0dc52ac (pull 715) Bugfix: comply with BIP 0014 ...
* f88dddc (pull 559) -acceptnonstdtxn option to skip "non-standard...
* 95d3e7e (pull 552) Typo-tolerant (optimized) Base58 parser
* 45beffe (pull 553) Parse URIs with non-BTC amounts
* 74439a5 (pull 562) Optimized binary-to-hex converter (ToHex)
Cannot be merged cleanly (at least not into next-test at this point):
* (pull 430) joelkatz optimizations
* (pull 452) JSON-RPC API versioning
* (pull 457) IPv6 JSON-RPC
* (pull 427) IPv6
Not yet written:
* Treat generation (almost) like normal receive
* JSON-RPC with integer amounts

2023-06-07 02:52:11

- reply

📅 Original date posted:2011-12-21
🗒️ Summary of this message: Mike Hearn asks if there is a way to improve Git's summaries for merge commits. Suggestion given to use `git log --no-merges`.
📝 Original message:On Wednesday, December 21, 2011 5:12:07 AM Mike Hearn wrote:
> Git does not produce very helpful summaries when every commit is a merge.
> Is there a way to fix that? You have to guess what a change does based on
> the name of the topic branch currently.
Not sure what you mean. Maybe `git log --no-merges` ?

2023-06-07 02:45:36

- reply

📅 Original date posted:2011-12-12
🗒️ Summary of this message: Using Namecoin has a similar issue as FirstBits, but .bit domains are inexpensive, while vanitygen slows down grabbing common words.
📝 Original message:On Monday, December 12, 2011 6:37:56 PM Jorge Timón wrote:
> Would it be too strange to use namecoin?
This has the same problem as FirstBits, except .bit domains are dirt cheap,
whereas vanitygen at least slows down grabbing all the common words...

2023-06-07 02:45:07

- 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:44:36

- 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

- 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

- 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

- 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

- 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

- 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:42:27

- reply

📅 Original date posted:2011-12-12
🗒️ Summary of this message: Base58 encoding is not ideal for human-readable addresses, and may need to be overhauled. Proposed changes to encoding for Bitcoin addresses.
📝 Original message:On Monday, December 12, 2011 3:56:01 PM Pieter Wuille wrote:
> It seems base58 is actually quite terrible for producing nice
> human-recognizable addresses, even though base58 is specially intended for
> human usage. We'll just have to deal with it, or completely overhaul it
> and move to a saner encoding.
Or both: use this proposal for 20-byte base58 for now, and overhaul it in the
future (maybe when the block chain forks?).
> 0: mainnet pubkey hashes ('1', as before)
> 192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
> 5: mainnet script hashes ('3'; for OP_EVAL)
> 196: testnet script hashes ('2', same as normal testnet addresses)
Looks good here.
> 12: mainnet private keys ('Q', 'R' or 'S', instead of 128, '5')
> 204: testnet private keys ('7', instead of 239, '8' and '9')
These are 32-byte, so have no reason IMO to follow the 20-byte proposal.
Since a lot of services are already using version 128 ('5') for bitcoin
private keys, and 128 is "reserved" in the 20-byte proposal, I think it's fair
to leave it alone (for now).

2023-06-07 02:42:20

- reply

📅 Original date posted:2011-12-10
🗒️ Summary of this message: A proposal suggests using bits to define network class and network for compatibility with Namecoin addresses, leaving the rest up to the network.
📝 Original message:This should make it compatible with Namecoin addresses...
Here's a revised proposal:
* Bits 128/64 define network class
** 0 = main network
** 64,128 = reserved
** 192 = test network
* Bits 32/16 define network
** 0 = Bitcoin
** 16 = reserved
** 32 = OTHER (next octet)
** 48 = Namecoin
The rest is left up to the network to decide; for Bitcoin, it is:
* Bits 8/4/2 define data class
** 0 = Public key hash
** 2 = reserved
** 4 = Script hash
** 6 = Public key (raw)
** 8 = Signature
** 10 = reserved
** 12 = Private key (raw)
** 14 = OTHER (next octet)
* Bit 1 is freely chosen (for aesthetic assignment)

2023-06-07 02:42:17

- reply

📅 Original date posted:2011-12-06
🗒️ Summary of this message: A revised proposal for addressing bugs in the spec includes defining network class, network, and data class using bits.
📝 Original message:Some bugs I found in my spec so far:
- Bitcoin public keys begin with '2' (same as testnet data)
- For the first first-class "aux" network, signatures and private keys will
start with the same character.
- More "collisions" are possible if the "reserved" values were ever assigned.
To address these slightly better, here's a revised proposal:
* Bits 128/64 define network class
** 0 = main network
** 64,128 = reserved
** 192 = test network
* Bits 32/16 define network
** 0 = Bitcoin
** 16,32 = reserved
** 48 = OTHER (next octet)
* Bits 8/4/2 define data class
** 0 = Public key hash
** 2 = reserved
** 4 = Script hash
** 6 = Public key (raw)
** 8 = Signature
** 10 = reserved
** 12 = Private key (raw)
** 14 = OTHER (next octet)
* Bit 1 is freely chosen (for aesthetic assignment)
Note that under this scheme, both script hashes and raw public keys begin with
'3'; I consider this a non-issue since neither are supported by current-
generation clients, and both pubkey-hash and script-hash are quite capable of
the same functionality as a raw public key. Also, the raw public key will
presumably be noticably longer.
For reference, a table of version number to first-base58-char mappings:
+........ 0 => 1
-.......1 1 => QRSTUVWXYZabcdefghijkmno
-......1. 2 => 2opqrstuvwxyz
+......11 3 => 2
-.....1.. 4 => 23
+.....1.1 5 => 3
+.....11. 6 => 3
-.....111 7 => 34
+....1... 8 => 4
-....1..1 9 => 45
+....1.1. 10 => 5
+....1.11 11 => 5
-....11.. 12 => 56
+....11.1 13 => 6
-....111. 14 => 67
+....1111 15 => 7
+...1.... 16 => 7
-...1...1 17 => 78
+...1..1. 18 => 8
-...1..11 19 => 89
+...1.1.. 20 => 9
+...1.1.1 21 => 9
-...1.11. 22 => 9A
+...1.111 23 => A
-...11... 24 => AB
+...11..1 25 => B
+...11.1. 26 => B
-...11.11 27 => BC
+...111.. 28 => C
-...111.1 29 => CD
+...1111. 30 => D
+...11111 31 => D
-..1..... 32 => DE
+..1....1 33 => E
-..1...1. 34 => EF
+..1...11 35 => F
+..1..1.. 36 => F
-..1..1.1 37 => FG
+..1..11. 38 => G
-..1..111 39 => GH
+..1.1... 40 => H
+..1.1..1 41 => H
-..1.1.1. 42 => HJ
+..1.1.11 43 => J
-..1.11.. 44 => JK
+..1.11.1 45 => K
+..1.111. 46 => K
-..1.1111 47 => KL
+..11.... 48 => L
-..11...1 49 => LM
+..11..1. 50 => M
+..11..11 51 => M
-..11.1.. 52 => MN
+..11.1.1 53 => N
-..11.11. 54 => NP
+..11.111 55 => P
+..111... 56 => P
-..111..1 57 => PQ
+..111.1. 58 => Q
-..111.11 59 => QR
+..1111.. 60 => R
+..1111.1 61 => R
-..11111. 62 => RS
+..111111 63 => S
-.1...... 64 => ST
+.1.....1 65 => T
+.1....1. 66 => T
-.1....11 67 => TU
+.1...1.. 68 => U
-.1...1.1 69 => UV
+.1...11. 70 => V
+.1...111 71 => V
-.1..1... 72 => VW
+.1..1..1 73 => W
-.1..1.1. 74 => WX
+.1..1.11 75 => X
+.1..11.. 76 => X
-.1..11.1 77 => XY
+.1..111. 78 => Y
-.1..1111 79 => YZ
+.1.1.... 80 => Z
+.1.1...1 81 => Z
-.1.1..1. 82 => Za
+.1.1..11 83 => a
-.1.1.1.. 84 => ab
+.1.1.1.1 85 => b
-.1.1.11. 86 => bc
+.1.1.111 87 => c
+.1.11... 88 => c
-.1.11..1 89 => cd
+.1.11.1. 90 => d
-.1.11.11 91 => de
+.1.111.. 92 => e
+.1.111.1 93 => e
-.1.1111. 94 => ef
+.1.11111 95 => f
-.11..... 96 => fg
+.11....1 97 => g
+.11...1. 98 => g
-.11...11 99 => gh
+.11..1.. 100 => h
-.11..1.1 101 => hi
+.11..11. 102 => i
+.11..111 103 => i
-.11.1... 104 => ij
+.11.1..1 105 => j
-.11.1.1. 106 => jk
+.11.1.11 107 => k
+.11.11.. 108 => k
-.11.11.1 109 => km
+.11.111. 110 => m
-.11.1111 111 => mn
+.111.... 112 => n
+.111...1 113 => n
-.111..1. 114 => no
+.111..11 115 => o
-.111.1.. 116 => op
+.111.1.1 117 => p
+.111.11. 118 => p
-.111.111 119 => pq
+.1111... 120 => q
-.1111..1 121 => qr
+.1111.1. 122 => r
+.1111.11 123 => r
-.11111.. 124 => rs
+.11111.1 125 => s
-.111111. 126 => st
+.1111111 127 => t
+1....... 128 => t
-1......1 129 => tu
+1.....1. 130 => u
-1.....11 131 => uv
+1....1.. 132 => v
+1....1.1 133 => v
-1....11. 134 => vw
+1....111 135 => w
-1...1... 136 => wx
+1...1..1 137 => x
+1...1.1. 138 => x
-1...1.11 139 => xy
+1...11.. 140 => y
-1...11.1 141 => yz
+1...111. 142 => z
+1...1111 143 => z
-1..1.... 144 => 2z
+1..1...1 145 => 2
+1..1..1. 146 => 2
+1..1..11 147 => 2
+1..1.1.. 148 => 2
+1..1.1.1 149 => 2
+1..1.11. 150 => 2
+1..1.111 151 => 2
+1..11... 152 => 2
+1..11..1 153 => 2
+1..11.1. 154 => 2
+1..11.11 155 => 2
+1..111.. 156 => 2
+1..111.1 157 => 2
+1..1111. 158 => 2
+1..11111 159 => 2
+1.1..... 160 => 2
+1.1....1 161 => 2
+1.1...1. 162 => 2
+1.1...11 163 => 2
+1.1..1.. 164 => 2
+1.1..1.1 165 => 2
+1.1..11. 166 => 2
+1.1..111 167 => 2
+1.1.1... 168 => 2
+1.1.1..1 169 => 2
+1.1.1.1. 170 => 2
+1.1.1.11 171 => 2
+1.1.11.. 172 => 2
+1.1.11.1 173 => 2
+1.1.111. 174 => 2
+1.1.1111 175 => 2
+1.11.... 176 => 2
+1.11...1 177 => 2
+1.11..1. 178 => 2
+1.11..11 179 => 2
+1.11.1.. 180 => 2
+1.11.1.1 181 => 2
+1.11.11. 182 => 2
+1.11.111 183 => 2
+1.111... 184 => 2
+1.111..1 185 => 2
+1.111.1. 186 => 2
+1.111.11 187 => 2
+1.1111.. 188 => 2
+1.1111.1 189 => 2
+1.11111. 190 => 2
+1.111111 191 => 2
+11...... 192 => 2
+11.....1 193 => 2
+11....1. 194 => 2
+11....11 195 => 2
+11...1.. 196 => 2
+11...1.1 197 => 2
+11...11. 198 => 2
+11...111 199 => 2
+11..1... 200 => 2
+11..1..1 201 => 2
+11..1.1. 202 => 2
+11..1.11 203 => 2
+11..11.. 204 => 2
+11..11.1 205 => 2
+11..111. 206 => 2
+11..1111 207 => 2
+11.1.... 208 => 2
+11.1...1 209 => 2
+11.1..1. 210 => 2
+11.1..11 211 => 2
+11.1.1.. 212 => 2
+11.1.1.1 213 => 2
+11.1.11. 214 => 2
+11.1.111 215 => 2
+11.11... 216 => 2
+11.11..1 217 => 2
+11.11.1. 218 => 2
+11.11.11 219 => 2
+11.111.. 220 => 2
+11.111.1 221 => 2
+11.1111. 222 => 2
+11.11111 223 => 2
+111..... 224 => 2
+111....1 225 => 2
+111...1. 226 => 2
+111...11 227 => 2
+111..1.. 228 => 2
+111..1.1 229 => 2
+111..11. 230 => 2
+111..111 231 => 2
+111.1... 232 => 2
+111.1..1 233 => 2
+111.1.1. 234 => 2
+111.1.11 235 => 2
+111.11.. 236 => 2
+111.11.1 237 => 2
+111.111. 238 => 2
+111.1111 239 => 2
+1111.... 240 => 2
+1111...1 241 => 2
+1111..1. 242 => 2
+1111..11 243 => 2
+1111.1.. 244 => 2
+1111.1.1 245 => 2
+1111.11. 246 => 2
+1111.111 247 => 2
+11111... 248 => 2
+11111..1 249 => 2
+11111.1. 250 => 2
+11111.11 251 => 2
+111111.. 252 => 2
+111111.1 253 => 2
+1111111. 254 => 2
+11111111 255 => 2

2023-06-07 02:37:17

- 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

- 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:32:53

- reply

📅 Original date posted:2011-10-10
🗒️ Summary of this message: Mike Hearn is developing custom software to efficiently create work for his pool, which will replace the use of bitcoind.
📝 Original message:On Monday, October 10, 2011 9:18:07 AM Mike Hearn wrote:
> > > > As I will no longer be using bitcoind for Eligius soon
> > >
> > > What will you be using instead? Isn't bitcoind a requirement for
> > > running
> >
> > a
> >
> > > pool?
> >
> > Writing some custom software designed to more efficiently create work.
> > To clarify, bitcoind will still serve the purpose of peering with
> > external nodes and picking out valid transactions to be accepted into
> > blocks; it just
> > won't be involved in the primary operations of the pool.
>
> Ah, I see. Sounds a bit like the direction Steve is going with poolserverj.
> So your custom software would handle incrementing the extraNonce,
> recalculating the merkle tree/root, and so on?
Yes, does that already. Hard part right now is implementing a stateless TCP/IP
"stack" so it can ignore DDoS sanely.

2023-06-07 02:32:47

- reply

📅 Original date posted:2011-10-10
🗒️ Summary of this message: Luke-Jr plans to stop using bitcoind for Eligius pool and create custom software for more efficient work creation while still using bitcoind for other purposes.
📝 Original message:On Monday, October 10, 2011 5:22:28 AM Mike Hearn wrote:
> On Sun, Oct 9, 2011 at 1:12 AM, Luke-Jr <luke at dashjr.org> wrote:
> > As I will no longer be using bitcoind for Eligius soon
>
> What will you be using instead? Isn't bitcoind a requirement for running a
> pool?
Writing some custom software designed to more efficiently create work.
To clarify, bitcoind will still serve the purpose of peering with external
nodes and picking out valid transactions to be accepted into blocks; it just
won't be involved in the primary operations of the pool.

2023-06-07 02:32:40

- reply

📅 Original date posted:2011-10-10
🗒️ Summary of this message: Luke-Jr requested Coinbaser to be merged for 0.5, citing extensive testing and support, but Gavin was unwilling to merge it before the feature freeze.
📝 Original message:On Saturday, October 08, 2011 7:12:31 PM Luke-Jr wrote:
> Please at least get Coinbaser merged for 0.5. It has had a lot of testing
> on Eligius for months, a landslide of support for the new JSON-RPC method
> (as requested), and I have even gone to the effort to document it. As I
> will no longer be using bitcoind for Eligius soon, I have little incentive
> to maintain/rebase coinbaser across a 0.6 development period.
FWIW, Gavin's IRC response more or less amounts to being unwilling to merge
this even though it was ready, tested, and even fulfilled his original request
for community support for the new JSON-RPC call, all long before he announced
the feature freeze on 0.5... hopefully it'll get merged to 0.6 git before it
needs a rebase. :/

2023-06-07 02:30:01

- reply

📅 Original date posted:2011-09-28
🗒️ Summary of this message: A proposal to simplify the internal reference miner by removing dependencies on cryptopp and the getwork "midstate" field is being discussed.
📝 Original message:On Tuesday, September 27, 2011 11:45:48 PM Jeff Garzik wrote:
> On Mon, Sep 26, 2011 at 3:42 PM, Nils Schneider <nils at nilsschneider.net>
wrote:
> > I'd like to simplify the internal reference miner and remove all
> > dependencies on cryptopp (it's the only place we use cryptopp instead of
> > OpenSSL).
> >
> > Unfortunately, cryptopp is also used to calculate getwork "midstate".
> > This field is redundant and the miner could easily calculate it from the
> > blockheader so I'd like to remove it.
> >
> > Any thoughts? Where should such a change should be announced so all
> > miners can be upgraded?
>
> I think one of the pools was already working on something like that?
> I'm pretty sure it can be removed, and I'm pretty sure somebody has
> already field-tested that guess.
I tested removing midstate myself, and found at least one miner (cpuminer
IIRC) requires it.

2023-06-07 02:29:43

- reply

📅 Original date posted:2011-09-26
🗒️ Summary of this message: Version bumped to 0.4.1, but it's a pre-release before the stable team's first release of 0.5.0.
📝 Original message:* 6b8a5ab Bump version to 0.4.1
This should be some pre-0.5.0, not 0.4.1 which will be the stable team's first
release...

2023-06-07 02:29:22

- reply

📅 Original date posted:2011-09-26
🗒️ Summary of this message: A discussion about the acceptance of transactions with "non-standard" sig op count in blocks, and the potential for DoS attacks.
📝 Original message:On Monday, September 26, 2011 5:38:41 PM Gavin Andresen wrote:
> > The first one I was referring to is a *transaction* with "non-standard"
> > sig op count, which is AFAIK allowed in blocks, just not accepted by the
> > mainline rules.
>
> I sit corrected. The context is:
> // Checking ECDSA signatures is a CPU bottleneck, so to avoid
> denial-of-service
> // attacks disallow transactions with more than one SigOp per 34
> bytes.
> // 34 bytes because a TxOut is:
> // 20-byte address + 8 byte bitcoin amount + 5 bytes of ops + 1
> byte script length
> if (GetSigOpCount() > nSize / 34 || nSize < 100)
> return DoS(10, error("AcceptToMemoryPool() : transaction with
> out-of-bounds SigOpCount"));
>
> I'm having trouble imagining some future world where valid,
> new-versions-agree-to-relay-transactions have more than one SigOp per
> 34 bytes; can you give an example?
It's not future. It's presently allowed in blocks. Which means it's perfectly
valid to relay (and also perfectly value to NOT relay or accept). Ergo,
shouldn't be punished.
> > Maybe the person spending it sees it matured beyond 100 confirmations,
> > and you only see 99. An attacker could use these things to get nodes to
> > ban each other.
>
> That would imply you're on a blockchain fork of more than 99 blocks
> with respect to the person spending the transaction, in which case I'd
> argue you have much bigger problems and it is a good idea for the DoS
> code to kick in and kick either you or them off the network...
Um, no? It implies you have 99 blocks since the coinbase, and he has 100 and
wants to spend. In this scenario, it's proper to reject his transaction *until
you have the next block*, but it doesn't make sense to punish for it.

2023-06-07 02:27:47

- reply

📅 Original date posted:2011-09-18
🗒️ Summary of this message: Amir Taaki suggests creating a repository on Github for Bitcoin Improvement Proposals (BEPs) where people can freely contribute.
📝 Original message:On Sunday, September 18, 2011 8:31:55 PM Amir Taaki wrote:
> Ideally these should go in a github.com/bitcoin/beps/ repo.
Please, somewhere people can freely commit to...

2023-06-07 02:27:35

- reply

📅 Original date posted:2011-09-20
🗒️ Summary of this message: Jeff Garzik suggests applying observations to Bitcoin, aligning with the goals of the #bitcoin-stable team.
📝 Original message:On Tuesday, September 20, 2011 3:10:16 PM Jeff Garzik wrote:
> Thus, we observe a few things that may be applied to bitcoin:
This is basically what the #bitcoin-stable team wants to do.

2023-06-07 02:27:23

- reply

📅 Original date posted:2011-09-19
🗒️ Summary of this message: Developers discuss the idea of creating a stable branch for Bitcoin to provide bug fixes with minimal changes and fewer risks of introducing new bugs.
📝 Original message:On Monday, September 19, 2011 8:49:08 AM Gavin Andresen wrote:
> On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr <luke at dashjr.org> wrote:
> > If we prepare the git repository + tags, would you guys be
> > willing to make the actual release builds + source, and/or post such on
> > the websites you administrate?
> > Luke and various others in #bitcoin-stable
>
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
>
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.
The problem with the current development model is that bugfixes are done
alongside improvements, and code changes *always* have the potential to
introduce new bugs, no matter how careful anyone is. So to stay on top of
bugfixes right now implies risking new bugs being introduced. What good is
getting one bug fixed, if it comes with 20 new yet-to-be-discovered bugs?
For example, 0.3.20.2 was the last version if bitcoind before people started
experiencing random (albeit rare) deadlocks. However, there have been many
bugfixes since then. Since there is no stable branch, someone who wishes to
get those bugfixes is forced to either create their own stable branch from
scratch, or risk getting all the new bugs introduced in the latest version
(most of which are unknown at this time).
On the other hand, a stable 0.4.x branch can provide people with upgrades
which they know make only the minimal changes required to fix bugs with a much
smaller risk of new bugs being introduced (not only are there fewer changes,
but bugfixes tend to also be less invasive changes). While there are arguably
still various "must-have" features missing from 0.4, having a stable branch
also allows people to maintain a stable+<feature I need> branch with greater
ease too.

2023-06-07 02:26:30

- 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:11

- 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

- 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:24:03

- reply

📅 Original date posted:2011-09-08
🗒️ Summary of this message: Bitcoin's alert system is crucial in case of network issues, especially against attackers with over 50% computational power, but it has never been used.
📝 Original message:On Thursday, September 08, 2011 3:43:12 PM theymos wrote:
> The alert system will be very important if there are ever any critical
> problems in the network. For example, it is currently Bitcoin's only
> defense against an attacker with >50% of the computational power, where
> alerts would be used to tell people to stop accepting transactions.
I don't seem to recall this ever happening, despite Deepbit having over 50%
multiple times now.

2023-06-07 02:19:57

- reply

📅 Original date posted:2011-08-31
🗒️ Summary of this message: John Smith uses qmake to build a project on Windows, MacOSX, and Linux and seeks guidance on setting build options.
📝 Original message:On Wednesday, August 31, 2011 10:20:48 AM John Smith wrote:
> The project builds on Windows, MacOSX and Linux using qmake.
How do you set build options with qmake?

2023-06-07 02:19:07

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Pieter Wuille suggests adding opcodes for accessing block height and removing the 100 confirmation requirement for spending generated coins.
📝 Original message:On Wednesday, August 24, 2011 12:18:54 PM Pieter Wuille wrote:
> While we're at it, some additional opcodes could be useful.
Also:
- Access to the block height it's part of. While this can be abused,
transactions accessing it can be given a big red flag in the GUI or
something. Legitimate uses include "Clearcoin" functionality in the script
itself.
- Remove the 100 confirmation requirement for spending generated coins. If
they are respent before 100 confirmations, clients can/should flag the new
outputs as also "generated" or "recently generated" so recipients are aware
of the risk. It would be especially handy for pool operators if blocks could
contain a transaction spending one of the same block's generation in
addition to other non-generated coins, and specifying the full amount as a
fee to safely add coins to the generation. Right now, if I were to embed a
25 BTC fee-only transaction, there is a risk that Deepbit could grab that
transaction for their own, and fork. By making pool payouts all generated,
there is no risk to paying invalid blocks instantly (since if the block is
invalid, so is the payout made in it).

2023-06-07 02:18:00

- 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

- 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:17:16

- reply

📅 Original date posted:2011-08-22
🗒️ Summary of this message: A discussion about integrating Bitcoin into general coding and implementation paradigms on GNU/Linux platforms, including the possibility of creating a standard for a wallet protocol.
📝 Original message:On Monday, August 22, 2011 3:30:04 PM Douglas Huff wrote:
> On Aug 22, 2011 2:26 PM, "Fred Concklin" <fconcklin at trucoin.com> wrote:
> > I'm also interested in work to daemonize bitcoin on boot and furthering
> > work to bring bitcoin into general coding and implementation paradigms
> > seen on GNU/Linux platforms.
>
> What? It already works fine in this regard using standard tools. Especially
> easy with daemontools/runit.
He said standard *coding and implementation paradigms*. This has nothing to do
with integration with some non-standard "init replacement" that goes against
the whole design of Unix.
What I understand this to mean, is properly abstracting the components such
that the node, wallet, and GUI can work together while being distinct parts.
In this sense, Fred, you may be interested in working on coming up with a
standard for a https://en.bitcoin.it/wiki/Wallet_protocol

2023-06-07 02:17:01

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: A one-line patch adapts to support boost filesystem version 3, which is required for Boost 1.48+, but it can be removed later.
📝 Original message:On Wednesday, August 24, 2011 3:19:08 PM Jeff Garzik wrote:
> On Fri, Aug 19, 2011 at 12:48 PM, Luke-Jr <luke at dashjr.org> wrote:
> > This patch conditionally adapts the one line needed to support boost
> > filesystem version 3 (default in Boost 1.46+ and required for 1.48+)
> >
> > I have tested it with Boost 1.41.0 to verify it still works on these
> > older versions too.
>
> Your change appears to be technically correct. It is disappointing
> for #ifdefs to crap up the code, though...
It's only one line, and can be removed when the old APIs are sufficiently
removed.

2023-06-07 02:16:55

- reply

📅 Original date posted:2011-08-19
🗒️ Summary of this message: This patch adds support for Boost filesystem version 3, which is required for Boost 1.48+ and has been tested on older versions.
📝 Original message:This patch conditionally adapts the one line needed to support boost
filesystem version 3 (default in Boost 1.46+ and required for 1.48+)
I have tested it with Boost 1.41.0 to verify it still works on these older
versions too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Support-for-boost-filesystem-version-3.patch
Type: text/x-patch
Size: 743 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20110819/2b9d25e4/attachment.bin>

2023-06-07 02:13:17

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: Luke-Jr accuses Jeff of not attributing the original author in a rewritten bugfix_CreateThread_leak, but later apologizes after being corrected.
📝 Original message:On Thursday, August 04, 2011 4:29:01 PM Luke-Jr wrote:
> Jeff, you seem to have rewritten *part of* bugfix_CreateThread_leak and
> neglected to attribute the original author (as my branch did/does).
My apologies. BlueMatt showed me how my comment here was wrong.
Hopefully I'll remember how GitHub shows merges like this in the future.

2023-06-07 02:13:14

- reply

📅 Original date posted:2011-08-04
🗒️ Summary of this message: Several branches are ready for merging, including bugfixes, internal function changes, and compliant support for all bitcoin URIs. Original authorship should be attributed.
📝 Original message:Reminder these are still ready for merging...
Jeff, you seem to have rewritten *part of* bugfix_CreateThread_leak and
neglected to attribute the original author (as my branch did/does).
> For the "3diff" version, I extracted and made proper git branches for each
> logical part:
> hub_mode
> threaded_rpc
> \-- rpc_keepalive (depends on threaded_rpc, or a single connection would
> keep the JSON-RPC interface locked up)
> signal_blk_notify (generic version of -pollpidfile, with a bugfix)
> bugfix_CreateThread_leak
> getwork_dedupe (original branch for my bugfix)
>
> In addition, I also consider these branches valid candidates for merging:
> coinbaser (popens a given command and reads coinbase outputs from stdout)
> gitignore (ignore some common misc files)
> minfee_modes (internal function changes to allow specifying different
> fees for relay, send, or accept-in-block)
> \-- eligius_relay (relay lower fees only Eligius will accept)
> \-- eligius_sendfee (send lower fees only Eligius will accept)
> txinfo (adds entries to getinfo for transactions accepted for relaying,
> transactions accepted for the current block-in-progress, and
> current block-in-progress size)
> bitcoinuri (compliant support for all bitcoin: URIs)
>
> All available from git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git

2023-06-07 02:05:06

- reply

📅 Original date posted:2011-07-13
🗒️ Summary of this message: A programmer defines a constant value based on a calculation, not just an arbitrary number.
📝 Original message:On Wednesday, July 13, 2011 9:04:09 AM Andy Parkins wrote:
> TCoinsElement MAX_MONEY;
This isn't an arbitrary constant, it's the result of a calculation...

2023-06-07 02:01:30

- 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.