> If we ban "arbitrary data", however you want to define it, then actors will
> simply respond by encoding their data within sets of public keys. Public
> key data is indistinguishable from random data, and, unless we are willing
> to pad the blockchain with proof of knowledge of secret keys, ther
> The white paper describing the proposal can be found here:
> https://github.com/LNP-BP/layer1/
Some questions about the Bitcoin PoW anchoring:
What if a miner spends the current miner single-use-seal while
creating a commitment, but makes the PMT only partially available, or
entirely unavailabl
> Right now the total reward per transaction is $63, three orders of magnitude
> higher than typical fees.
No need to exaggerate; this is only two orders of magnitude higher
than current fees, which are typically over $0.50
___
bitcoin-dev mailing list
b
> There's only one coin whose expected (soft) emission time is larger
> than bitcoin's, and it's about an order of magnitude larger, at 50
> years.
Make that two coins. For DOGE it is 33 years.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundati
> The emission curve lasts over 100 years because Bitcoin success state
> requires it to be entrenched globally.
It effectively doesn't. The last 100 years from 2040-2140 only emits a
pittance of about 0.4 of all bitcoin.
What matters for proper distribution is the shape of the emission
curve. I
A parallel discussion is taking place at
https://bitcointalk.org/index.php?topic=5405755.0
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> New blog post:
> https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
A Tail Emission is best described as disinflationary; the yearly
supply inflation steadily decreases toward zero.
> Dogecoin also has a fixed reward
It started out with random rewards up to 1M doge per b
On Fri, 6 May 2022 7:17PM Jorge Tim?n wrote
> But let's not personally attack andreas for his opinions.
> The only reason you don't like bip8 is because you're ignorant about it and
> you haven't reviewed it enough.
Can you see the irony in equating "clueless about BIP119" with a
personal attack a
> Alternately, one possible softforkable design would be for Bitcoin to
> maintain a non-CT block (the current scheme) and a separately-committed CT
> block (i.e. similar to how SegWit has a "separate" "block"/Merkle tree that
> includes witnesses).
> When transferring funds from the legacy non-
A possible way of obscuring the Mimblewimble transaction graph with
multi-party non-interactive coinswaps is described at
https://forum.grin.mw/t/mimblewimble-coinswap-proposal
Feedback is more than welcome.
regards,
-John
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimbl
Re: Floating-Point Nakamoto Consensus (bitcoin ml)
>
> This is a pretty big departure from cumulative POW.
It's still cumulative. But instead of cumulating network difficulty,
they cumulate log_2(solution difficulty).
So if two solutions are found simultaneously, and one has a hash
that's only h
n them.
>
> A sort of self-referential negative trigger.
> Each instance of the kernel would delay the next instance for at least the
> specified lockheight number of blocks.
>
> John Tromp wasted no time in naming this "No Recent Duplicate" or NRD locks.
>
> An N
dear mimblewimblers,
I'd like to propose a potential alternative way to implement relative
time locks. It possibly qualifies as a "crazy idea" as Antioch alluded
to below. It can be thought of as a negative trigger.
I propose to call it a "No Such Kernel Recently" or NSKR lock.
Suppose we have tr
> However, my understanding is that, at least with the original
> mimblewimble.txt from Jedusor, the signatures and the
> Pedersen-commitment-to-0 could all be aggregated into a single signature and
> Pedersen-commitment-to-0, if we were to use Schnorr-like signatures.
Non-interactive aggregata
dear ZmnSCPxj,
> Which I suppose is my point: you lose some of the "magic shrinking
> blockchain" property in implementing relative locktimes, as you now increase
> the data you have to store forever (i.e. the kernels).
The "magic shrinking" of MW never applied to kernels. To validate the
curre
> However, I believe that Lightning and similar offchain protocols are **not
> possible** on MimbleWimble, at least if we want to retain its "magical
> shrinking blockchain" property.
MimbleWimble can easily incorporate relative lock heights, in addition
to absolute lock heights. Grin and Beam h
I took a first stab at creating a MimbleWimble Wikipedia entry at
https://en.wikipedia.org/wiki/MimbleWimble
regards,
-John
--
Mailing list: https://launchpad.net/~mimblewimble
Post to : mimblewimble@lists.launchpad.net
Unsubscribe : https://launchpad.net/~mimblewimble
More help : https://
dear Gary,
> 5. Alice calculates (q*P) and attach it to the transaction kernel as the
> restriction to spend its PTXO. ONLY who owns the private key of this public
> (q*P) can spend this PTXO.
> To summarize the difference of the transaction kernel between ITX and PTX,
> PTX has 3 additional f
dear Antioch,
> The problem with outputs though is nodes only maintain data relating to
> _unspent_ outputs (the UTXO set).
> Spent outputs are removed and effectively act as if they never existed. This
> is a core tenet of the scalability (and privacy) of MW.
> So if we refer to an output we appe
at the bottom of my Go page http://tromp.github.io/go.html, which also
contains an sgf link.
Direct link to image: http://tromp.github.io/img/WO5lives.png
Enlarging the board to 29x29 allows for a much better final (I hope)
look, close to my first attempt.
-John
___
> The hunt for the simplest possible ko gadget continues...
Latest attempt at the usual place:
>>> at the bottom of my Go page http://tromp.github.io/go.html, which also
>>> contains an sgf link.
>>> Direct link to image: http://tromp.github.io/img/WO5lives.png
Unfortunately not as pretty as the
> Hopefully fixed now.
Nope. Still no good. White can play O13, M11, or Q11 instead of recapturing ko.
The hunt for the simplest possible ko gadget continues...
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/list
> I assume after white plays at U22
This fails the goal of saving White O5, as Black will just P5, and
White's only means of escape,
with the ladder M3 N4 N5 M5 M6, fails when Black directs it to N17.
___
Computer-go mailing list
Computer-go@computer-go.
>>> Direct link to image: http://tromp.github.io/img/WO5lives.png
Might be useful for go event organizers in need of arrow signs...
regards,
-John
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-
>> I have attempted to reduce this y || (x && z) problem to the minimum
>> number of stones
>> at the bottom of my Go page http://tromp.github.io/go.html, which also
>> contains an sgf link.
>> Direct link to image: http://tromp.github.io/img/WO5lives.png
>
> Unfortunately, my ko gadgets don't work
> I have attempted to reduce this y || (x && z) problem to the minimum
> number of stones
> at the bottom of my Go page http://tromp.github.io/go.html, which also
> contains an sgf link.
> Direct link to image: http://tromp.github.io/img/WO5lives.png
Unfortunately, my ko gadgets don't work properl
> If we call the three kos x,y,z from top to bottom, then a succesfull
> White ladder amounts to
> (x || y) && (y || z). Which is equivalent to y || (x && z).
> So with y currently false, and White unable to flip it, White should
> take the bottom ko to make z true.
> Black can the make x false, bu
P hard instances. However, without a proof this
> assumption is still as valid as (1).
>
> I am curious what's John Tromp opinion on the above.
I spent some time thinking about the loss-less-ladder problem, that
asks if Black can capture
a given white group in a ladder without lo
On Tue, Jun 19, 2018 at 12:03 PM, Marcel Crasmaru wrote:
>> White can start one ladder as a ko threat to take back the middle ko, and
>> black will then take the top ko.
> I claim that White cannot use the ladders as a ko thread because:
> - if W plays R4 as a ko threat then B responds with S4
On Tue, Jun 19, 2018 at 3:52 AM, Marcel Crasmaru wrote:
> I've eventually managed to create a problem that should show a full
> reduction from a Robson problem to Go - I hope is correct.
>
> The Problem:
> https://drive.google.com/file/d/1tmClDIs-baXUqRC7fQ2iKzMRXoQuGmz2/view?usp=sharing
> Black
On Mon, Jun 18, 2018 at 10:24 PM, Álvaro Begué wrote:
> I don't think ko fights have anything to do with this. John Tromp told
> me that ladders are PSPACE complete: https://tromp.github.io/lad.ps
Ko fights are needed to take Go problems beyond PSPACE.
For Japanese rules they su
On Mon, Jun 18, 2018 at 10:30 PM, Marcel Crasmaru wrote:
>> FWIW, first-capture go (i.e. winner is first one to make a capture) should
>> not be PSPACE-complete.
>
> Actually this is not obvious.
>
> If you are able to replace the White Choice gadget shown at page V in
> this paper: https://tromp
A few days ago I wondered if grin could accept not only cuckoo30
solutions, but cycles in larger graphs as well. A cuckoo31 graph for
instance has twice as many nodes, and takes about twice as much effort
to search. But scaling the difficulty only by half provides little
incentive to work on larger
dear Ruben,
> Olivia will publish "yes" or "no" under her key O and commitment R.
>
> This means there are two possible values for S:
>
> S1 = R + hash(R, "yes")*O
> S2 = R + hash(R, "no")*O
>
> Alice and Bob create a payment channel under key A + B = C with 1 BTC each.
>
> They propose two possib
hi Luke,
> current crypto-currencies with the exception of monero are based
> around the principle of hiding... so of course they are being hunted
> and hounded. monero and i believe grin-coin at least provide both
> privacy *and traceability*, such that an individual may *prove* to
> their local
dear David,
> To quote from: http://tromp.github.io/go/legal.html
>
> It should come as no surprise that L19, viewed as a position, is itself
> illegal.
>
> In this absolute form this statement got disproved in my German Go Forum
> article at
> http://www.dgob.de/yabbse/index.php?topic=5935.msg216
dear Igno,
>> Should we give up on the possibility to burn coins, and give up on
>> incentivizing small blocks, because of the perceived complexity of
>> a subtraction?
>
> There's a little more complexity involved. First, you have to think about
> fast-synced pruned nodes. They have to know abou
dear Ignotus,
> I like the idea, it's simple and elegant and seems to put the right
> incentives in place.
>
> I don't like that it relies on burn. It puts us between a rock and a hard
> place as we either:
>
> * Materialize the burn as specific outputs and keep them forever, bloating
> the cha
> Is the total miner reward calculated as: BaseReward - Burn [BaseReward * (N
> / MaxN)^2] + N * TxFee ?
That's a simplification of the general formulation where all
transactions have the same #inputs,
#outputs, #kernels, and fee.
The burning can be implemented either as a reduction in reward, or
Grin testnet1 burns half the tx fee in an attempt to incentivize
against block bloat. But this attempt fails since miners can still
spam a block with their own 0-fee transactions, or accept user's 0-fee
transactions while demanding an out-of-band fee payment that is not
subjected to fee burning.
O
> Wouldn't this create an incentive for a miner to include all transactions
> with fees attached from the mempool and publish the block with a time stamp
> enough in the future to allow that size of block?
Yes, it clearly provides incentives to lie about timestamps,
which I think is enough to make
> Slightly off-topic for a logo but I'm enjoying our friend U+1F601 here:
>
> https://unicode-table.com/en/1F601/
feels very much on topic!
I would agree that an actual grin is to be preferred over a stylized G
(which is why I hardly like any of the 99designs).
regards,
-John
--
Mailing list: h
A little close to Gold Coin's perhaps
https://www.gldcoin.com/
On Thu, Nov 9, 2017 at 10:06 AM, Fola Adejumo wrote:
> Hi All
>
>
> I have some logo updates. See attached.
>
> Let me know your thoughts.
>
>
> Thanks in advance,
>
>
>
> --
> *From:* Fola Adejumo
> *
On Thu, Nov 2, 2017 at 3:39 PM, John Tromp wrote:
> The attached plot summarizes how the bitcoin emission compares to that of grin
> over the first 200 years, assuming a 2% yearly loss of coins.
Here's the same plot, as well as one for inflation, as a gif.
Maybe these can be add
On Thu, Nov 2, 2017 at 3:36 PM, John Tromp wrote:
> dear grinners,
> The attached plot summarizes how the bitcoin emission compares to that of grin
> over the first 200 years, assuming a 2% yearly loss of coins.
Oops; forgot to attach...
bitcoin.grin.02.pdf
Description: Adobe PDF
dear grinners,
The attached plot summarizes how the bitcoin emission compares to that of grin
over the first 200 years, assuming a 2% yearly loss of coins.
It was produced from the C program below.
Use arguments -l 0 for the lossless bitcoin emission,
no arguments for bitcoin with 2% loss, and
-s
> You can also start with 9x9 go. That way games are shorter, and you probably
> don't need 1600 network evaluations per move to do well.
Bonus points if you can have it play on goquest where many
of us can enjoy watching its progress, or even challenge it...
regards,
-John
__
On Tue, Oct 17, 2017 at 9:42 AM, Alberto Garcia wrote:
> That means that to account and prove ownership
> of your money you should keep a set of private keys. Am I correct? If I am,
> is there a way to simplify the user the "trouble" of having so many keys?
Yes, your wallet will normally store yo
> I'll compare with bitcoin which I guess most
> people consider the "standard" supply schedule.
>
> If you run the numbers, assuming you acquired bitcoin at the end of the
> first year, at the end of year 10 (which is coming fast) you will be diluted
> by a factor of 6.5. Now with a flat coin supp
On Mon, Oct 2, 2017 at 8:53 AM, Alessandro Viganò wrote:
> Right now is important to design a good monetary policy but not a perfect
> one. I believe it’s impossible to foresee what is coming in years. So some
> flexibility is needed, and, in any case, the ultimate flexibility is called
> forking
On Sun, Oct 1, 2017 at 3:10 PM, Garrick Ollivander
wrote:
> Let's assume we want 0% dilution after grin reaches Visa like 2000 tx/s use
> use with a block time of 10 seconds,
That's completely unrealistic. Bandwidth wise, grin scales worse than bitcoin,
with transactions taking well over 2KB, mo
dear Seamus,
> The 7 years of rewards, plus the many hints at eventually switching to Proof
> of Stake and reducing rewards, make Ethereum an altogether bad point of
> comparison. Around 72 million coins were distributed via the crowdfunding
> sale and to the foundation/developers. Then another 12
> BUT, observing implied chain intrinsic interest rate is impossible without
> on-chain transfer of ownership of those zero bonds. Transfer of ownership is
> however prohibited until maturity, at which point the zero bond becomes
> cash. If a transfer before maturity was possible, then those new ze
dear all,
In the very first message to this list, I made a proposal for
a block reward schedule, involving some exponential stepping.
In retrospect that seems overly complicated. The simplest
possible schedule, namely a fixed constant block reward,
probably works well enough. It's also what Ether
> Transaction fees are mostly a mechanism to prevent transaction flooding.
The block size limit should be the primary mechanism for that.
> Space and bandwidth in a blockchain network are scarce resources and free
> transactions would lead to abuse.
The abuse would be due to a lack of informatio
dear imblers,
I'm happy with the name "grin" for both the implementation and the coin.
Naming of the smallest unit is not that important, and we could just go
with nanogrin if we deviate from the 10^-8 subdivision by adopting the more
metric compatible 10^-9 subdivision. Otherwise, I'm also fine w
> Shouldnt that number at most be 722^#positions? Since adding a black or a
> white stone is something fundamentally different?
The upper bound of 361^L(19,19) games is from Theorem 7 on page 31 of
http://tromp.github.io/go/gostate.pdf, where you will find a proof.
As the paragraph preceding that
> And what is the connection between the number of "positions" and the number
> of games
The number of games is at most 361^#positions.
> or even solving games? In the game trees we do not care about
> positions, but about situations.
We care about lots of things, including intersections, stones
> Under which ruleset is the 3^(n*n) a trivial upper bound for the number of
> legal positions?
Under all rulesets.
> Unless we talk about simply the visual aspect
Yes, we do.
> but then this has
> absolutely nothing to do with the discussion abour solving games.
If you want the notion of "pos
> There is a definition of “brute force” on Wikipedia.
https://en.wikipedia.org/wiki/Brute-force_search explains it as
"systematically enumerating all possible candidates for the solution".
There is nothing systematic about the pseudo random variation
selection in MCTS; it may not even have suffi
dear Igno,
> So I'm considering a switch to the Blake2 [3] hash function. It's extremely
> fast in software (faster than SHA256 and even MD5), has been shown to be as
> secure as SHA3, was designed independently and has been widely reviewed.
>
> Any strong opposition or concerns?
On the contrary.
> Under "Transacting with MimbleWimble" a new curve G is introduced:
>
>> For these reasons, we introduce a second ECC curve G and a
>> private key r used as a blinding factor.
>
> And this curve G is used for Point addition:
>
>> r*G + v*H
>
> Two questions, are G and H in the same group in secp25
dear Igno,
This is a tough decision! If scalable quantum computers are our
only worry, then there's a lot to be said for Pedersen. I love its
simplicity and efficiency. And it seems likely that such quantum
computers will make their presence known in some way or other.
But we still cannot take cl
dear Igno,
> BIP152 introduced a good solution by introducing short transaction ids
> (which we can generalize to inputs/outputs/kernels):
>
> https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#Short_transaction_IDs
>
> It does force a full re-hashing of the pool on each block but siph
dear John,
> Thanks for the update. Just curious, what's the time tradeoff for that 20x
> memory? This optimization becomes difficult, especially on GPU, over Cuckoo
> 30, correct?
The speedup is about 4x on a cpu. But since the solver becomes more similar
to an Equihash solver (both dominated by
dear Ignotus/all,
> Some decent mining software that can handle multiple GPUs.
There has been some significatn development in Cuckoo Cycle.
Xenoncat, the anonymous Zcash miner contest winner, recently
claimed a $5000 CPU speedup bounty, by using 20x more memory
to bucketsort the edge->endpoint m
hi Ingo,
>> “Pair Go” — A game where one Chinese pro will play
>> against another...except they will both have their own
>> AlphaGo teammate, alternating moves, to take the concept
>> of ‘learning together’ quite literally.
>
> Will the pro players in these games see the evaluations
> of AlphaGo?
>> (Japanese rules are not *that* hard. IIRC, Many Faces, and all other
>> programs, including my own, scored in them
>
> There is a huge difference between doing some variation of territory
> scoring and implementing Japanese rules. Understanding this difference
> will get you some way to understa
> I agree with the need to enable non-repudiation in transactions. I
> originally had a simpler scheme in mind (basically the sender adds a nonce
> to the blinding factor, the receiver puts his blinded output, the sender
> subtracts the nonce*G from total and builds the sig) but there may be
> adva
The original whitepaper at
http://mimblewimble.cash/20160719-OriginalWhitePaper.txt
proposes the following transaction creation procedure:
1. Sender and recipient agree on amount to be sent. Call this b.
2. Sender creates transaction with all inputs and change output(s), and gives
recipi
dear imblers,
> Each output has a rangeproof consisting of several ring signatures
> corresponding to different denominations that sum to the hidden value
> (see [1] [2]).
> For binary denominations, each such ring signature is of the form
> (e0,s0,s1) satisfying, for some P0,P1 differing by 2^i *
dear imblers,
While discussing kernel signatures and possible optimizations with Igno,
I got this idea about how to single-handedly turn ordinary outputs
into 2-of-2 outputs with myself as additional recipient, effectively
holding them at ransom. Note that this attack seems limited to the use
of S
> Do inputs ever need to be recorded in a block?
Yes; either explicitly as the pedersen commitment, or implcitly as follows
Inputs could be represented compactly in 8 bytes, either as
4 byte block index + 4 bytes output-within-block index,
or as 8 byte entire-output-history index.
> For instance
> Ok, so I think where we're headed is:
>
> - We should generalize blocks to "frankenblocks" which are ranges of
> consecutive blocks where cutthrough inputs and outputs are pruned
>
> - We should have a better name for frankenblock :)
I somewhat disagree. We don't need new kinds of blocks
dear Ethan,
> I can see how aggregate block is confusing terminology. I'm going to
> avoid using it in the future.
>
> What I meant was that the blocks B1+B2 are sent together and that
> possible cut-throughs have already been applied in both blocks.
You can not apply any changes to existing bloc
Answers below according to my understanding...
> What is MimbleWimble default behavior in the event that a block
> contains a doublespend? Is the block invalid like in Bitcoin?
Yes, every input must be an unspent output, and can appear at most once
in a block.
> 1. An attacker computes a block B
> The people constructing the locktimes are depending on the security of the
> zero-knowledge proof (which could be as simple as just hashes being random
> oracles) and the security of the timelock puzzles (RSA problem being hard).
>
>> I don't see the downside of simply requiring a locktime on eve
dear Andrew,
>> Pieter Wuille in particular has stressed to me what a great feature of MW it
>> is
>> that everything looks the same, and that breaking this property should be
>> taken
>> very seriously.
But with every kernel having both a fee and a locktime (which defaults
to the last confirme
A while ago I had a chat with Andrew in
https://gitter.im/grin_community/Lobby where he helped explain multi
signature transactions to me, and I thought it might benefit others as
well to explain the atomic swap below in more detail.
So the setting is that Igno holds some coins on the MW altchain,
dear Igno,
> That is, the receiver will look up how many kernel she has matching the hint.
> If 0 or more than 1, it will query peers for a list of all known
> matching kernels.
Uhm, that should be: ask the sending peer to expand the hint to a full kernel.
regards,
-John
--
Mailing list: https
dear Igno,
>> The second largest piece of data is composed of the transaction kernels
>> (~100 bytes each). We can't fully avoid sending those as they're not
>> "anchored" on anything, like the range proof is anchored on an output.
>> However we could send a shortened version of their hash. In thi
dear Igno,
> In this discussion, I'm only interested in the size of a block when sent
> across the wire during propagation. It's desirable in this context to have
> small block sizes (in bytes) so that blocks can traverse the network quickly
> without causing too much additional traffic. As most n
hi Bo,
> Let me know if there is any silly mistakes :)
You say "the perfect policy network can be
derived from the perfect value network (the best next move is the move
that maximises the value for the player, if the value function is
perfect), but not vice versa.", but a perfect policy for both
dear Gellert,
>> If we were to limit ourselves to at most 6 halvings, i.e. a minimum tail
>> reward of REWARD / 64, then with peaking set to occur after 4 years,
>> this tail won't
>> be reached until 64*4 = 256 years into the future, at which point
>> we're long dead. (In bitcoin it only takes 6
dear imblers,
Ignotus and me both seem to share the opinion that a tail-less (i.e.
fees only) schedule may be undesirable.
Currently the code appears to just set the reward to a constant
REWARD, with halving yet to be implemented. (I noticed a comment typo
where it says the reward should be deduc
1. An intended play must be legal -- no playing on top of a stone hoping
it 'falls' to the neighbor positions.
> The point of the rule is ease of implementation for computer programs,
> to promote adoption. A program that already plays Go will probably keep
> tabs on legal plays, not eve
>> On frisbee Go itself I used the following definition:
>> 1. An intended play must be legal -- no playing on top of a stone hoping
>> it 'falls' to the neighbor positions.
>
> Accepted.
What's the point of this rule?
I feel it is an unnecessary restriction, similar to the no-suicide rule,
and w
dear Go researchers,
>> > Found a 582 move 3x3 game...
>> Can you give us sgf?
>
> I took the effort of trying to format the 582 game in a more insightful way.
> I ended up with lines of positions that mostly add stones, only starting
> a new line when a capture of more than 1 stone left at most 4
dear Aja,
> AlphaGo is getting stronger and stronger. I hope you all will enjoy watching
> the games.
Could you tell us if Alpha Go is able to come up with that most famous of moves:
http://senseis.xmp.net/?EarReddeningMove
Or is it so strong that it found an even better move:-?
regards,
-John
dear Ingo,
>>> ... (1 + delta)^(m*n).
>>
>> This is true, and a delta > 2 follows from a Theorem in an
>> upcoming paper by Matthieu Walraet and myself.
>
> Do you mean (1+delta) > 2, or really (1+delta) > 3?
Oops; I mean delta >= 1, so the base of the exponent is at least 2.
(1+delta) is necess
dear Nick,
> There's an assumption implicitly made here, which does not accord with my
> experience of frisbee Go: that the player will always aim at an
> intersection.
>
> Suppose I want to play on either of two adjacent points, and I don't care
> which. If I aim for one of them, I will land on o
dear Darren, Ingo,
> Again by random sampling?
Yes, nothing fancy.
> Are there certain moves(*) that bring games to an end earlier, or
> certain moves(*) that make games go on longer? Would weighting them
> appropriately in your random playouts help?
You could try to weigh moves by how likely t
I don't remember if there was consensus, but can repeat my previous thoughts:
> 1. What happens with plays unintentionally on top of stones or out of
> bounds?
Converted to involuntary pass.
Note that a throw must have some positive probability of converting into
a legal move. This way, infinitel
> The longest I've been able to find, by more or less random sampling,
> is only 521 moves,
Found a 582 move 3x3 game...
regards,
-John
___
Computer-go mailing list
Computer-go@computer-go.org
http://computer-go.org/mailman/listinfo/computer-go
dear Go researchers,
Finding the maximum length of a Go game, if we measure length
by number of (non-pass) moves, is equivalent to finding the longest
simple path in the game graph.
For 2x2 this can easily be brute forced, and one finds a maximum
length of 48 moves (so a single game can visit at
On Wed, Jan 27, 2016 at 1:46 PM, Aja Huang wrote:
> We are very excited to announce that our Go program, AlphaGo, has beaten a
> professional player for the first time. AlphaGo beat the European champion
> Fan Hui by 5 games to 0.
It's interesting to go back nearly a decade and read this 2007 art
For those of you who missed it, chess grandmaster Hikaru Nakamura,
rated 2787, recently played a match against the world's top chess program
Komodo, rated 3368. Each of the 4 games used a different kind of handicap:
Pawn and Move Odds
Pawn Odds
Exchange Odds
4-Move Odds
As you can see, handicaps
> You must be kidding about Lee Sedol.
> ...
> So he was by far the biggest fish Google could ever catch for that
> game, for Go insiders as well as for people outside the Go scene.
Well said, Marc.
In terms of name recognition and domination in the past decade,
who else but Lee Sedol should be p
dear Robert,
>> It will never be known since there's not enough space in the known
>> universe to write it down. We're talking about a number with over
>> 10^100 digits.
>
> How do you know that an implicit expression (of length smaller than 10^80)
> of the number does not exist? :)
Of course an
dear Robert,
> The number G19 of legal games under a given go ruleset is unknown.
It will never be known since there's not enough space in the known
universe to write it down. We're talking about a number with over
10^100 digits.
> For positional
> superko (prohibition of recreation of the same
1 - 100 of 218 matches
Mail list logo
